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

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

<p>Therefore the attack he describes is a fork-based double spend similar to his questions <a href="https://bitcoin.stackexchange.com/questions/32635/json-rpc-to-detect-double-spent-txs">here</a> and <a href="https://bitcoin.stackexchange.com/questions/32678/how-to-recover-from-a-double-spending-attack">here</a>.</p>

CC BY-SA 3.0
2014-11-25T15:01:35.590Z
2014-11-25T15:01:35.590Z
2017-04-13T12:47:33.583Z
David A. Harding
<p>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 <code>raw transactions</code> interface. </p>

<p>What is going to happen in this case:</p>

<ul>
<li>The service receives 3 payments by 3 different users.</li>
<li>All payments are included into the next block so they now have one confirmation.</li>
<li>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.</li>
<li>A few seconds later a double-spend attack in one of the TX's (now-spent) outputs comes in place.</li>
</ul>

<p>As I find it hard to reproduce the scenario above, my question is:</p>

<ol>
<li>What is the best way for the service to detect this double-spending attack through the RPC API?</li>
<li>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?</li>
</ol>

CC BY-SA 3.0
2014-11-25T03:21:21.237Z
I feel like this is a repeat of the answered questions you asked [here](http://bitcoin.stackexchange.com/questions/32635/json-rpc-to-detect-double-spent-txs) and [here](http://bitcoin.stackexchange.com/questions/32678/how-to-recover-from-a-double-spending-attack).  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](http://bitcoin.stackexchange.com/questions/32664/bitcoind-confirmations-during-fork/32666#32666).
David A. Harding
CC BY-SA 3.0
2014-11-25T11:30:25.367Z
@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](http://bitcoin.stackexchange.com/questions/32678/how-to-recover-from-a-double-spending-attack) 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
CC BY-SA 3.0
2014-11-25T13:20:25.070Z
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
CC BY-SA 3.0
2014-11-25T13:38:58.413Z
@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
CC BY-SA 3.0
2014-11-25T14:04:30.177Z
that is correct.
David A. Harding
<json-rpc><doublespend><raw-transaction><race-attack>
How to detect a race attack and re-spend the already-spent outputs?
Doug Peters
# How to detect a race attack and re-spend the already-spent outputs?

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

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?

**Tags:** json-rpc, doublespend, raw-transaction, race-attack

> **Comments:**
> **username_1**: I feel like this is a repeat of the answered questions you asked [here](http://bitcoin.stackexchange.com/questions/32635/json-rpc-to-detect-double-spent-txs) and [here](http://bitcoin.stackexchange.com/questions/32678/how-to-recover-from-a-double-spending-attack).  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](http://bitcoin.stackexchange.com/questions/32664/bitcoind-confirmations-during-fork/32666#32666).  
> **username_0**: @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](http://bitcoin.stackexchange.com/questions/32678/how-to-recover-from-a-double-spending-attack) 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?  
> **username_1**: 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?  
> **username_0**: @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?  
> **username_1**: that is correct.  

---

## 1 answers

### Answer by username_1 on 2014-11-25. Score: 1 | Accepted answer

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](https://bitcoin.stackexchange.com/questions/32635/json-rpc-to-detect-double-spent-txs) and [here](https://bitcoin.stackexchange.com/questions/32678/how-to-recover-from-a-double-spending-attack).


---

