<p>I can't speak for what it does <em>every</em> time but I just tested Mr. Schwartz's comment, so I can speak for what it did this <em>one</em> 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 &amp; 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 <code>-rescan</code></p>

<p>Curiously, after the <code>-rescan</code> the second transaction doesn't even show in a <code>bitcoind listtransactions</code> 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 <em>is</em> 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.</p>

CC BY-SA 3.0
2011-09-09T08:07:19.223Z
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](https://github.com/bitcoin/bitcoin) so people looking for things to work on have a chance to see this issue.
David Schwartz
CC BY-SA 3.0
2011-09-09T08:10:31.230Z
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
CC BY-SA 3.0
2011-09-09T14:40:07.570Z
[BitcoinCharts](http://bitcoincharts.com/bitcoin/) 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
CC BY-SA 3.0
2011-09-13T18:20:57.540Z
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
CC BY-SA 3.0
2012-09-17T01:31:57.070Z
Has this ever made it into the standard client? Or is there any other means to detect lost transactions?
makerofthings7
CC BY-SA 3.0
2011-09-08T05:22:10.887Z
2011-09-08T05:22:10.887Z
David Perry
<p>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?  <strong>What actually happens in the default client when two conflicting transactions are received?</strong></p>

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

CC BY-SA 3.0
2011-09-08T01:00:35.990Z
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
CC BY-SA 3.0
2011-09-08T01:05:58.197Z
But what _does_ it do right now?
eMansipater
CC BY-SA 3.0
2011-09-08T01:08:26.947Z
I don't know, that's why I commented rather than answering.
David Schwartz
<transactions><client><doublespend>
What does the Bitcoin client do when it receives conflicting transactions?
eMansipater
# What does the Bitcoin client do when it receives conflicting transactions?

(Asked by: username_0 on 2011-09-08)

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.

**Tags:** transactions, client, doublespend

> **Comments:**
> **username_1**: 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.  
> **username_0**: But what _does_ it do right now?  
> **username_1**: I don't know, that's why I commented rather than answering.  

---

## 1 answers

### Answer by username_2 on 2011-09-08. Score: 16 | Accepted answer

I can't speak for what it does *every* time but I just tested Mr. username_1'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.

> **Comments:**
> **username_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](https://github.com/bitcoin/bitcoin) so people looking for things to work on have a chance to see this issue.  
> **username_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).  
> **username_2**: [BitcoinCharts](http://bitcoincharts.com/bitcoin/) 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.  
> **username_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.  
> **username_3**: Has this ever made it into the standard client? Or is there any other means to detect lost transactions?  

---

