j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMÍ<div class="post">I think the important point is that these things are unavoidable unsafe after a certain point, even for listreceivedbyaddress. So I think it's helpful to compare current website behavior under mainline bitcoin, with listtransactions. Let us call this the <b>confirmation point</b>. Addressing your queries...<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292">Quote from: satoshi on December 08, 2010, 10:36:45 PM</a></div><div class="quote">1) How do you know if a past transaction becomes invalid and disappears?<br/></div><br/>bitcoinmarket and mtgox and other sites seem to consider 6 confirmations their "confirmation point", the moment at which a transaction may be considered "safe." If a past transaction becomes invalid and disappears, the website cannot avoid potential loss, because the user has already received their PayPal-USD or LR-USD or Pecunix GAU and disappeared.<br/><br/>Same for a web store or brick-and-mortar store. There is a confirmation point at which the customer receives goods. If a TX becomes invalid after that, the store takes an unavoidable loss, because the customer is already gone with the purchased goods.<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292">Quote from: satoshi on December 08, 2010, 10:36:45 PM</a></div><div class="quote">2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.<br/></div><br/>Let us assume that confirmation count for txid 0x1234 is bouncing wildly between 0 to 10 to 0 and back and forth, due to a large number of block reorgs.<br/><br/>Whether it is listreceivedbyaddress or listtransactions, you still have a binary confirmation point, a moment in time, at which the transaction crosses the "approved by store" level of confidence. At that confirmation point, the customer leaves with purchased goods, and store takes a loss regardless of further block chain or TX behavior.<br/><br/>I do agree a programmer may make a mistake, and assume that number of confirmations will always increase. But that human mistake, too, will cause danger when used with listreceivedbyaddress.<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292">Quote from: satoshi on December 08, 2010, 10:36:45 PM</a></div><div class="quote">3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.<br/></div><br/>On <i>this</i> point, I agree that listtransactions presents some additional danger here, due to changing txid, <i>if and only if</i> the new double-spend matches destination bitcoin address being sought by the JSON-RPC user.<br/><br/>Nevertheless, in this case too, the user's security rests entirely on their level of confidence: if the TX is replaced before 6 confirmations, software will likely not notice anything. If the TX is replaced after 6 confirmations, the customer has already left with purchased goods, and the bitcoin user takes a loss.<br/><br/><br/>This is simply inherent to bitcoin itself. A block chain reorg <i>might</i> happen after 50 blocks. But websites do not want to make their users wait 50 blocks before receiving goods. It is the well-known snack machine problem. listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.<br/><br/>Transactions can and will be replaced after the binary "confirmation point." All users of bitcoin must figure this into their business plans, just like they account for credit card chargeback risk or shoplifting risk.</div> text/html
https://whatsonchain.com/tx/f35fdaeefef9d7a0e27d3df482a6dffcf020a8f1a6365cd093cde86ffd588e28