user14319: 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:

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


user21052: 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.

14319: <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>
 21052: <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>
