How to recover from a double spending attack?

Question

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_3and 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 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?

Answer 1

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.

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