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?
  • 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. Commented Nov 25, 2014 at 3: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? Commented Nov 25, 2014 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? Commented Nov 25, 2014 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? Commented Nov 25, 2014 at 13:38
  • that is correct. Commented Nov 25, 2014 at 14:04

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.