JSON-RPC method idea: list transactions newer than a given txid

It’s not safe to use listtransactions this way.

I know I’ve been criticized for being reluctant about listtransactions.  Let me explain my reluctance.

Transactions are dynamic.  Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend.  Their date can change, their order can change.

Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I’ll keep my own tally or static record of them.  This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:

1. How do you know if a past transaction becomes invalid and disappears?
2. When there’s a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3. A transaction can be replaced by a double-spend with a different txid.  You would count both spends.

The model where you assume you only need to see new transactions because you’ve already seen previous transactions is not true.  Old transactions can change at any time.

Any time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.

Now that we have the Accounts feature making it easier to do it the right way, we’re better prepared to have listtransactions.

Then how do you cope with the issues I listed in the message you quoted?

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.

Quote from: satoshi on December 08, 2010, 10:36:45 PM2) When there’s a block-chain reorg, it would be easy to double-count transactions when they get confirmed again. The OP’s example of listtransactions [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.

Quote from: jgarzik on December 08, 2010, 11:07:22 PMQuote from: satoshi on December 08, 2010, 10:36:45 PM3) 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. 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.

Quote from: jgarzik on December 09, 2010, 12:58:05 AMI agree with you and satoshi about “txs after ”.  My listtransactions (now xlisttransactions) patch pointedly does not have that feature, and never has. As long as the interface is designed for things like showing the user the last N transactions history, it’s fine, now that we have the Accounts feature making it easier to do payment detection the right way.

Gavin, could listtransactions have an option to list transactions for all accounts?

I’m not sure what the interface could be, maybe: listtransactions [count]

It would be hard to do that from the command line though.

I can’t think of a good solution for the interface, that’s the problem.  Maybe "" special case like "" is.  Everyone would have to make sure no user can create account name "".

Quote from: jgarzik on December 09, 2010, 04:13:50 PMSure, and that’s easy enough to track with transactions. I don’t get how that’s “easy” to track with transactions.