But he and others says different on IRC. (Some confusion about timestamps (which I don't use) redacted – too long already.):
20:28 < sturles> Question: I have an autobuy system where I give each seller an unique address to transfer to when selling, and use a
-walletnotify script to trigger a price check when someone transfer coins to their address. When the transaction
confirms, it will write details to a file I send to the bank to do payments.
20:28 < sturles> How will this work if a tx is changed?
20:29 < sturles> Will bitcoind be able to track the changed confirmed transaction and connect it to the unconfirmed one I received?
20:29 < sturles> Otherwise the seller will get the wrong price.
20:29 < sturles> Just noticed Gavin's claim that "Transactions are always tracked properly by the Bitcoin-Qt/bitcoind software".
20:29 < sturles> If that is correct, I have nothing to worry about.
20:30 < Luke-Jr> A new txid is treated as a separate transaction
20:31 < sturles> This is what I feared. So it is not strictly true that bitcoind will track those transactions properly.
20:31 < Luke-Jr> depends on what one means by "properly" I suppose
20:33 < sturles> I use walletnotify to notify a script, and the script checks the current price. It notes the time as well, but my current
time.
20:33 < gavinandresen> sturles: if you are doing this at zero confirmations, then that is a very bad idea.
20:33 < Luke-Jr> sturles: ok, same thing in this case
20:34 < Luke-Jr> gavinandresen: only the price is determined by receive time, in his example
20:34 < gavinandresen> sturles: if you are only transferring money when the transaction has more than one confirmation, then no
worries
20:34 < Luke-Jr> I presume he waits for it to confirm before actually sending
20:34 < sturles> I check the price at zero confirmations, and write to a file which is going to the bank when the transaction is confirmed.
20:34 < sturles> I do not pay out at zero confirmations.
20:35 < Luke-Jr> sturles: for a quick fix, I suggest applying sipa's patch and matching up the "new txid" thing
20:35 < sturles> Users want to get as close to the current price as possible.
20:35 < Luke-Jr> sturles: be aware your system can be gamed though..
20:35 < Luke-Jr> sturles: I send a transaction that won't confirm on its own; if price drops, I double-spend. if it goes up, I confirm it
20:36 < Luke-Jr> or vice-versa might actually be the bad case..
20:36 < sturles> Wouldn't this be possible with the payment protocol as well?
20:36 < gavinandresen> If the "you" is a mining pool, then you can do this even if transactions were immutable.
20:36 < Luke-Jr> sure, that's the risk of doing 0 confirm for price
20:36 < gavinandresen> (even if transaction IDs were immutable, I mean)
20:36 < Apocalyptic> indeed
20:37 < Luke-Jr> gavinandresen: for example, CPFP could make a transaction mined only when a user decides
20:37 < sturles> I will log the unconfirmed tx and can ban users who try double spending tricks. No problem really.
20:38 < Luke-Jr> sounds like a plan to me
20:38 < sturles> So I will need sipa's patch to track changed transactions properly in my case?
20:39 < Luke-Jr> that will protect your customers from third parties, yes
20:39 < Luke-Jr> it will still break if your users do CoinJoins, but that's less urgent I guess
20:39 < gavinandresen> sturles: see also:
https://github.com/bitcoin/bitcoin/pull/335420:40 < sturles> I still do manual checks before anything is going to the bank, and the system will warn strongly if the balances don't match
up (e.g. confirmed transaction reversal).
20:42 < Luke-Jr> it would probably be best if B-Qt in the future tracked when TxnA is replaced by TxnB and treated them as the same in a UI
sense
20:42 < Luke-Jr> but that's a lot of coding/review/etc
Conclusion: Bitcoin-Qt/bitcoind does not track changed transactions properly. Changed transactions will show up as a new transaction, and I would need the "new txid" thing to track those properly. It is not only MtGox. Services using bitcoind, like mine, may be vulnerable as well.
