> Quote from: satoshi on December 08, 2010, 10:36:45 PM > 2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again. > Quote from: jgarzik on December 08, 2010, 11:07:22 PM > Quote from: satoshi on December 08, 2010, 10:36:45 PM > > 3) A transaction can be replaced by a double-spend with a different txid. You would count both spends. > > listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress. > Quote from: satoshi on December 08, 2010, 10:36:45 PM > 3) A transaction can be replaced by a double-spend with a different txid. You would count both spends. I'm not talking about the normal risk for a given minconf level, I'm talking about additional pitfalls from listtransactions when used this way. The OP's example of listtransactions <account> [count=10] [txid] seems to imply and it would be very easy for programmers to assume that if they pass in the last txid of the previous call to listtransactions, they will never see the same transaction more than once, which is not the case. It would be very easy to double-count payments if you don't maintain your own persistent map or dictionary to track which txid's you've already accepted. It doesn't seem right to have a function that seems tailor made to be used a certain obvious way, and that way is a non-obvious trap. Suppose both spends are to the same address. getreceivedbyaddress would always count only one or the other spend at any given time, never both. Using listtransactions, it would be very easy to count both. You see the first spend, you count it. You see the second spend, you count it. Total is double counted.
Sponsors 
