<p>TX_1 is invalid because it is in conflict with the newly confirmed TX_5.  TX_3 and TX_4 are also invalid because they depend on TX_1.</p>

<p>TX_2 remains a valid transaction.  However, if Mr. Hacker's double spend attack involved orphaning the single block in which TX_1 and TX_2 were both contained, then TX_2 no longer appears on the block chain and now has 0 confirmations.  But nothing prevents it from being included in a future block, and assuming it has a fee attached, every miner on the network has an incentive to include it in their blocks.  So it would likely be confirmed quickly.  (In principle, there could be an opportunity here for Mr. Legit to double-spend and invalidate TX_2 if he wishes, but it would probably require the connivance of one or more powerful miners.)</p>

<p>What Mr. Smith's wallet shows him about the now-invalid TX_4 is up to that software.  Some might just show it stuck at 0 confirmations.  Others might display a more specific method that it has been invalidated.  In either case, they would hopefully make it clear that he is not currently able to spend those coins.</p>

<p>Assuming Service still owes money to Mr. Legit and Mr. Smith, they will need to create new transactions to pay them.  Obviously they can no longer spend the outputs of TX_1, nor can they spend TX_2 until it is reconfirmed.  They may need to instead spend other UTXOs they control, or if they don't have any, they will have to acquire some more coins from somewhere.</p>

<p>I don't think there is any way Service can avoid a repeat attack, short of simply waiting for more confirmations.  If they have some way of distinguishing Mr. Hacker from their other customers, they could impose a higher confirmation requirement on him alone.  Incoming transactions from other customers could continue to be spent immediately, while those from Mr. Hacker are held for additional confirmations before being spent.  That would reduce the possibility for Mr. Hacker's attacks to interfere with Service's other outgoing transactions.</p>

CC BY-SA 3.0
2014-11-22T23:00:01.563Z
Looks correct, except that TX\_2 can be spent even before it confirms.
David A. Harding
CC BY-SA 3.0
2014-11-22T23:12:35.100Z
@DavidA.Harding: I guess that's true in principle.  Many clients will not allow this by default, though, and if Service does create a new transaction TX_6 spending TX_2, TX_6 cannot confirm until TX_2 does.
Nate Eldredge
CC BY-SA 3.0
2014-11-22T22:57:07.627Z
2014-11-22T22:57:07.627Z
Nate Eldredge
<p>I had to diagram this out as the transactions and block chain might actually appear:</p>

<pre><code>    Inputs/Prev Outpoints    Outpoints
TX1 A:0                      TX1:0, TX1:1
TX2 B:0                      TX2:0
TX3 TX1:0, TX2:0             ?
TX4 TX1:1                    ?
TX5 A:0                      TX5:0


                (TX5)
Block A ------&gt; Block C ----&gt; Block D
         \
          ----&gt; Block B
                (TX1, TX2)
</code></pre>

<p>To answer your questions:</p>

<ol>
<li><p>TX3 and TX4 are not valid in any block chain which does not previously include TX1.  TX1 can't be included if TX5 is already a part of that chain because TX1 and TX5 both spend outpoint A:0.</p></li>
<li><p>TX2 is never invalid, so it If the wallet sending TX2 downloaded the now-stale block, it would've shown 1 confirmation. After the wallet switched to the new best block chain, it would show 0 confirmations again because neither block C nor block D includes it. After another block on the best block chain does include it, it'll return to 1 confirmation and increase from there.</p></li>
<li><p>If the service still wants to make the same payments, it has to create new transactions (TX6, TX7) using inputs that are still valid (e.g. TX2:0). If it attempts to resend TX3 or TX4, other nodes may ban it for attempting to relay invalid transactions.</p></li>
<li><p>To prevent future fork-based double spend attacks, the service either has to wait for more confirmations or find some non-Bitcoin way to collect money from double spenders, such as requiring registration with state-issued identification.  I know requiring more confirmations requires waiting more time, which is inconvenient, but it's the only decentralized method we have for reducing fraud risk.</p></li>
</ol>

CC BY-SA 3.0
2015-03-24T12:17:13.263Z
Why would block C and block D not include TX2? There is no conflict, so there is no reason why not both competing blocks B and C could confirm TX2.
Murch
CC BY-SA 3.0
2015-03-24T16:37:04.420Z
@Murch blocks C and D are created by Mr Hacker, and the lowest risk way for him to execute his attack would be a Finney attack, so he might not have knowledge of the subsequent TX2 at the time he creates those blocks.  However, you are correct that nothing stops the inclusion of TX2 in blocks C and D---I imply that in my bullet #2.  (Side note: this whole scenario is way too confusing, I must've really wanted upvotes back when I wrote this answer.)
David A. Harding
CC BY-SA 3.0
2014-11-22T22:56:58.303Z
2014-11-22T22:56:58.303Z
David A. Harding
<p>I found myself incapable of answering what would happen in this case, so here it is:</p>

<ul>
<li><p>A hacker (<code>Mr Hacker</code>) spends <code>UTXO_1</code> and <code>UTXO_2</code> in <code>TX_1</code>, depositing the monetary value of all <code>TX_1</code>'s outputs into a <code>Service</code> (eg a payment processor).</p></li>
<li><p>A legitimate user (<code>Mr Legit</code>) spends <code>UTXO_3</code> in <code>TX_2</code>. Again, <code>TX_2</code>'s outputs targets the same <code>Service</code> </p></li>
<li><p>Both <code>TX_1</code> and <code>TX_2</code> make it into the same block and get one confirmation by the network.</p></li>
<li><p>The <code>Service</code> immediately spends <code>UTXO_1</code> and <code>UTXO_3</code> in <code>TX_3</code> to pay <code>Mr Legit</code> and <code>UTXO_2</code> in <code>TX_4</code> to pay <code>Mr Smith</code>.</p></li>
<li><p><code>Mr Hacker</code> then decides to double-spend <code>TX_1</code> and for that reason he creates <code>TX_5</code> which "redirects" all outputs to himself. <code>Mr Hacker</code> is a miner so he is able to perform all the hashing work to make the double-spend successful. He is also lucky and the double-spend succeeds.</p></li>
</ul>

<p>So the question is:</p>

<ol>
<li><p>Have all TXs before <code>TX_5</code> (TXs: 1,2,3,4) been invalidated or just <code>TX_1</code>, <code>TX_3</code>and <code>TX_4</code> (<code>TX_3</code> and <code>TX_4</code> spent an output previous controlled by <code>TX_1</code> which was double-spent)?</p></li>
<li><p><code>Mr Legit</code> could see 1 confirmation for <code>TX_2</code> before the double-spending. What does he see now? What does <code>Mr Smith</code> see in his wallet, before and after the double-spending?</p></li>
<li><p>The <code>Service</code> <a href="https://bitcoin.stackexchange.com/a/32636/14319">realizes that a double-spending took place</a> and needs to recover from that broken state. What does it have to do to get back to normal operation? Does it have to re-send all the TXs? Does it still have in place the deposits made by <code>TX_2</code> after the double-spending or does it have to do something to re-claim these outputs?</p></li>
<li><p>How can the <code>Service</code> prevent <code>Mr Hacker</code>, who also has plenty of money to spend, from repeating the same process forever just to ruin the <code>Service</code>'s smooth operation, rather than (the <code>Service</code>) waiting for more confirmations before sending out the payments?</p></li>
</ol>

CC BY-SA 3.0
2015-03-24T12:18:45.837Z
It is confusing that you reuse UTXO_1 in the fourth step. What is it supposed to be? UTXO_1 and UTXO_2 were used in the first step in TX_1 which created **one** new output, as TX_1 only has one recipient. Also, why can both the service and the hacker spend UTXO_1? It would probably be easier to understand if you added a diagram and/or used unique names for all elements used in your scenario.
Murch
<transactions><doublespend><hacking>
How to recover from a double spending attack?
Doug Peters
# How to recover from a double spending attack?

(Asked by: username_0 on 2014-11-22)

I found myself incapable of answering what would happen in this case, so here it is:

* A hacker (`Mr Hacker`) spends `UTXO_1` and `UTXO_2` in `TX_1`, depositing the monetary value of all `TX_1`'s outputs into a `Service` (eg a payment processor).
* A legitimate user (`Mr Legit`) spends `UTXO_3` in `TX_2`. Again, `TX_2`'s outputs targets the same `Service`
* Both `TX_1` and `TX_2` make it into the same block and get one confirmation by the network.
* The `Service` immediately spends `UTXO_1` and `UTXO_3` in `TX_3` to pay `Mr Legit` and `UTXO_2` in `TX_4` to pay `Mr Smith`.
* `Mr Hacker` then decides to double-spend `TX_1` and for that reason he creates `TX_5` which "redirects" all outputs to himself. `Mr Hacker` is a miner so he is able to perform all the hashing work to make the double-spend successful. He is also lucky and the double-spend succeeds.

So the question is:

1. Have all TXs before `TX_5` (TXs: 1,2,3,4) been invalidated or just `TX_1`, `TX_3`and `TX_4` (`TX_3` and `TX_4` spent an output previous controlled by `TX_1` which was double-spent)?
2. `Mr Legit` could see 1 confirmation for `TX_2` before the double-spending. What does he see now? What does `Mr Smith` see in his wallet, before and after the double-spending?
3. The `Service` [realizes that a double-spending took place](https://bitcoin.stackexchange.com/a/32636/14319) and needs to recover from that broken state. What does it have to do to get back to normal operation? Does it have to re-send all the TXs? Does it still have in place the deposits made by `TX_2` after the double-spending or does it have to do something to re-claim these outputs?
4. How can the `Service` prevent `Mr Hacker`, who also has plenty of money to spend, from repeating the same process forever just to ruin the `Service`'s smooth operation, rather than (the `Service`) waiting for more confirmations before sending out the payments?

**Tags:** transactions, doublespend, hacking

> **Comments:**
> **username_1**: It is confusing that you reuse UTXO_1 in the fourth step. What is it supposed to be? UTXO_1 and UTXO_2 were used in the first step in TX_1 which created **one** new output, as TX_1 only has one recipient. Also, why can both the service and the hacker spend UTXO_1? It would probably be easier to understand if you added a diagram and/or used unique names for all elements used in your scenario.  

---

## 2 answers

### Answer by username_2 on 2014-11-22. Score: 2

TX\_1 is invalid because it is in conflict with the newly confirmed TX\_5. TX\_3 and TX\_4 are also invalid because they depend on TX\_1.

TX\_2 remains a valid transaction. However, if Mr. Hacker's double spend attack involved orphaning the single block in which TX\_1 and TX\_2 were both contained, then TX\_2 no longer appears on the block chain and now has 0 confirmations. But nothing prevents it from being included in a future block, and assuming it has a fee attached, every miner on the network has an incentive to include it in their blocks. So it would likely be confirmed quickly. (In principle, there could be an opportunity here for Mr. Legit to double-spend and invalidate TX\_2 if he wishes, but it would probably require the connivance of one or more powerful miners.)

What Mr. Smith's wallet shows him about the now-invalid TX\_4 is up to that software. Some might just show it stuck at 0 confirmations. Others might display a more specific method that it has been invalidated. In either case, they would hopefully make it clear that he is not currently able to spend those coins.

Assuming Service still owes money to Mr. Legit and Mr. Smith, they will need to create new transactions to pay them. Obviously they can no longer spend the outputs of TX\_1, nor can they spend TX\_2 until it is reconfirmed. They may need to instead spend other UTXOs they control, or if they don't have any, they will have to acquire some more coins from somewhere.

I don't think there is any way Service can avoid a repeat attack, short of simply waiting for more confirmations. If they have some way of distinguishing Mr. Hacker from their other customers, they could impose a higher confirmation requirement on him alone. Incoming transactions from other customers could continue to be spent immediately, while those from Mr. Hacker are held for additional confirmations before being spent. That would reduce the possibility for Mr. Hacker's attacks to interfere with Service's other outgoing transactions.

> **Comments:**
> **username_3**: Looks correct, except that TX\_2 can be spent even before it confirms.  
> **username_2**: @username_3: I guess that's true in principle.  Many clients will not allow this by default, though, and if Service does create a new transaction TX_6 spending TX_2, TX_6 cannot confirm until TX_2 does.  

---

### Answer by username_3 on 2014-11-22. Score: 2

I had to diagram this out as the transactions and block chain might actually appear:

```
    Inputs/Prev Outpoints    Outpoints
TX1 A:0                      TX1:0, TX1:1
TX2 B:0                      TX2:0
TX3 TX1:0, TX2:0             ?
TX4 TX1:1                    ?
TX5 A:0                      TX5:0

                (TX5)
Block A ------> Block C ----> Block D
         \
          ----> Block B
                (TX1, TX2)

```

To answer your questions:

1. TX3 and TX4 are not valid in any block chain which does not previously include TX1. TX1 can't be included if TX5 is already a part of that chain because TX1 and TX5 both spend outpoint A:0.
2. TX2 is never invalid, so it If the wallet sending TX2 downloaded the now-stale block, it would've shown 1 confirmation. After the wallet switched to the new best block chain, it would show 0 confirmations again because neither block C nor block D includes it. After another block on the best block chain does include it, it'll return to 1 confirmation and increase from there.
3. If the service still wants to make the same payments, it has to create new transactions (TX6, TX7) using inputs that are still valid (e.g. TX2:0). If it attempts to resend TX3 or TX4, other nodes may ban it for attempting to relay invalid transactions.
4. To prevent future fork-based double spend attacks, the service either has to wait for more confirmations or find some non-Bitcoin way to collect money from double spenders, such as requiring registration with state-issued identification. I know requiring more confirmations requires waiting more time, which is inconvenient, but it's the only decentralized method we have for reducing fraud risk.

> **Comments:**
> **username_1**: Why would block C and block D not include TX2? There is no conflict, so there is no reason why not both competing blocks B and C could confirm TX2.  
> **username_3**: @username_1 blocks C and D are created by Mr Hacker, and the lowest risk way for him to execute his attack would be a Finney attack, so he might not have knowledge of the subsequent TX2 at the time he creates those blocks.  However, you are correct that nothing stops the inclusion of TX2 in blocks C and D---I imply that in my bullet #2.  (Side note: this whole scenario is way too confusing, I must've really wanted upvotes back when I wrote this answer.)  

---

