How to detect a race attack and re-spend the already-spent outputs?

0

My service automatically accepts, processes and sends payments to its users. It connects to bitcoind through its JSON-RPC API and makes use of the raw transactions interface.

What is going to happen in this case:

  • The service receives 3 payments by 3 different users.
  • All payments are included into the next block so they now have one confirmation.
  • Upon one confirmation, the service forms a new TX that spends these 3 outputs. The appropriate fee is attached. The TX is now valid but unconfirmed.
  • A few seconds later a double-spend attack in one of the TX's (now-spent) outputs comes in place.

As I find it hard to reproduce the scenario above, my question is:

  1. What is the best way for the service to detect this double-spending attack through the RPC API?
  2. Once it detects the double-spending and realizes that the TX will never get confirmed, can it re-spend the same outputs (not including the one that has been double-spent) right away in the case of a race-attack?

Doug Peters

Posted 2014-11-25T03:01:22.663

Reputation: 1 326

2

I feel like this is a repeat of the answered questions you asked here and here. If this is a real risk for your service, I highly recommend that you sit down with the regtest mode and develop a solid unit test you can run against your production code. There's a basic example in this answer.

– David A. Harding – 2014-11-25T03:21:21.237

@DavidA.Harding thanks for the suggestion regarding the test procedure and all your great replies so far. Please correct me if I'm wrong but AFAIU this question describes a fork-based double-spending attack, while the question above refers to a race-based double-spending attack, which in my understanding is a totally different case, isn't it?

– Doug Peters – 2014-11-25T11:30:25.367

I'm confused. In bullet #1, you receive outputs a, b, c from TX1, TX2, and TX3. In bullet #2, these TXes get one confirmation. In bullet #3, you use those outputs as inputs a, b, c to create TX4. What exactly happens in bullet #4? A double spend which invalidates TX1, TX2, or TX3 would require a fork (see previous answers). A double spend using inputs a, b, or c to invalidate TX4 would need to be created by the same private keys your service uses or some multisig thing; is that a risk here? Or are you paying other people and worrying about whether they double spend TX4's outputs? – David A. Harding – 2014-11-25T13:20:25.070

@DavidA.Harding my bad for not making it clear, thanks for pointing it out. What I had in mind is that the attacker would broadcast two conflicting TXs in rapid succession with the malicious one getting propagated faster than the other that pays my service. If I had just spent the outputs of this TX (which would have 1 conf) to form another one (TX4) how should the service behave? But I think I get what you're saying: if there is at least 1 conf by the network a race-based double-spending attack is not possible, while a fork-based double-spending attack is, is that correct? – Doug Peters – 2014-11-25T13:38:58.413

that is correct. – David A. Harding – 2014-11-25T14:04:30.177

Answers

1

As Doug said in the question comments (posted here as an answer by his request):

If there is at least 1 conf by the network, a race-based double-spending attack is not possible.

Therefore the attack he describes is a fork-based double spend similar to his questions here and here.

David A. Harding

Posted 2014-11-25T03:01:22.663

Reputation: 10 154

Asked: 2014-11-25T03:01:22.663

Viewed: 188 times

Active: 2014-11-25T15:01:35.590