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.
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
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.