21

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.

Improve this question
3
  • 3
    I 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
    Sep 8, 2011 at 1:00
  • But what does it do right now?
    – eMansipater
    Sep 8, 2011 at 1:05
  • 1
    I don't know, that's why I commented rather than answering.
    – David Schwartz
    Sep 8, 2011 at 1:08

1 Answer 1

Reset to default
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.

Improve this answer
5
  • 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
    Sep 9, 2011 at 8:07
  • 1
    I 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
    Sep 9, 2011 at 8:10
  • 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
    Sep 9, 2011 at 14:40
  • 1
    They 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
    Sep 13, 2011 at 18:20
  • Has this ever made it into the standard client? Or is there any other means to detect lost transactions?
    – makerofthings7
    Sep 17, 2012 at 1:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.