What does the Bitcoin client do when it receives conflicting transactions?

21

2

I've been assuming that the second transaction will simply be discarded as invalid, while the first waits at 0/unconfirmed until it actually gets into a block (requiring a "-rescan" or similar if the second one actually ends up in the blockchain instead). But is this the case? What actually happens in the default client when two conflicting transactions are received?

For simplicity's sake assume the person running the client is the recipient of at least one of the transactions, and is not mining.

eMansipater

Posted 2011-09-08T00:33:05.117

Reputation: 13 466

3I know that what is supposed to happen is that it ignores all conflicting transactions and keeps the first one it received until a conflicting transaction gets in the block chain. Then it's supposed to forget the original transaction and stick with the one that got in the chain, even if that chain subsequently is invalidated. Kind of quirky, and that's what it's supposed to do! It is agreed that the client doesn't handle this well and may not even do what it's supposed to. – David Schwartz – 2011-09-08T01:00:35.990

But what does it do right now? – eMansipater – 2011-09-08T01:05:58.197

1I don't know, that's why I commented rather than answering. – David Schwartz – 2011-09-08T01:08:26.947

Answers

16

I can't speak for what it does every time but I just tested Mr. Schwartz's comment, so I can speak for what it did this one time. I remote controlled a geographically distant machine running an identical copy of Bitcoin on it and my local PC (with identical wallets). I sent identical conflicting transactions for my entire balance within a few milliseconds of each other (atomic clock sync & timers - don't ask) and just as expected, both transactions showed in both clients at 0/unconfirmed and only one made it into a block. The other disappeared after a -rescan

Curiously, after the -rescan the second transaction doesn't even show in a bitcoind listtransactions dump which seems odd to me. It seems like such erroneous transactions should be recorded and marked with a special status, similar to how orphaned block rewards are - this is an accounting system after all and under certain circumstances this could be "destroying evidence." I'll make a comment next time I'm on GitHub and see if someone bites.

David Perry

Posted 2011-09-08T00:33:05.117

Reputation: 13 848

1They were only 'right' by luck. Until one or the other transaction is confirmed, there's no way to know which one will 'win'. If you want to take unconfirmed transactions, it is a good idea to check several different points in the network. – David Schwartz – 2011-09-13T18:20:57.540

Has this ever made it into the standard client? Or is there any other means to detect lost transactions? – goodguys_activate – 2012-09-17T01:31:57.070

1

Thanks. I 100% agree that the client should store such transactions in a special state (invalidated, conflicted, whatever). It just doesn't currently have any code to do that. This should probably be filed as an enhancement request on GitHub so people looking for things to work on have a chance to see this issue.

– David Schwartz – 2011-09-09T08:07:19.223

1I actually did not expect both transactions to show up on both clients because a client won't pass a conflicting transaction. But I now know why it happened and where my reasoning went wrong -- each client got both transactions from different clients it was connected to. While every client not involved only kept and relayed the transaction it got first, a client will keep two conflicting transactions if they involve addresses in that client's own wallet (at least until one gets into a block). – David Schwartz – 2011-09-09T08:10:31.230

BitcoinCharts did show the correct transaction in its unconfirmed list almost immediately, however and ONLY showed the one which did eventually confirm, so it seems like best practice might be to check with such a third party rather than trust the local client for 0/unconfirmed transactions. – David Perry – 2011-09-09T14:40:07.570

Asked: 2011-09-08T00:33:05.117

Viewed: 2 963 times

Active: 2011-09-08T05:22:10.887