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
  • 1,366
  • 15
  • 23
  • 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 Nov 25 '14 at 03:21
  • @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 Nov 25 '14 at 11:30
  • 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 Nov 25 '14 at 13:20
  • @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 Nov 25 '14 at 13:38
  • that is correct. – David A. Harding Nov 25 '14 at 14:04

1 Answers1

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.

Community
  • 1
David A. Harding
  • 11,906
  • 2
  • 46
  • 72