<p>You may use an external service like <a href="https://www.blockcypher.com/dev/bitcoin/#confidence-factor" rel="nofollow noreferrer">blockcypher's confidence factor</a> to have an idea of whether or not a double spent attack will be performed. It seems to base its evaluation on the number of nodes a transaction has reached and its mining fee.</p>

<p>A transaction is not guaranteed to be present in the next block depending on the fees of the transactions present in the pool and the fee of the transaction. So the delay may be long before confirmation. Using such heuristics may prove helpful to shorten your business process.</p>

CC BY-SA 3.0
2017-06-05T06:05:01.427Z
'Well, to detect a double spend attack you have to check the network for additional tx with the same utxos, which can enter the pool before a block is confirmed with any of those concurrent tx.'  <- This comment by @Gabriel is acutally the correct answer. The checked answer goes on telling stories without  addressing the core question asked
dark knight
CC BY-SA 3.0
2017-02-13T17:45:44.800Z
2017-02-13T17:45:44.800Z
Gabriel
<p>Essentially, there is no such thing as a "suspicous transaction" and bitcoin is already set up to work in the way that you want.</p>

<p>Double spending is handled like this -- if two transactions spending the same input(s) happen in the same block, both will be rejected. If one transaction makes it into a block before the other, the first one will be accepted and the second will be rejected.</p>

<p>Now, if two transactions entered the network simultaneously, but at different endpoint, by the time the next block is mined it's likely that they would have made it into the same block and thus be simultaneously rejected. It's also possible that a block is mined containing one transaction, and all subsequent blocks containing the other transaction will simply be rejected. The third and least likely scenario is that two blocks are mined simultaneously -- each containing one of the competing transactions -- and this would cause a fork in the blockchain. However, this is the purpose of having confirmations, and by the time you reach 6, it's extremely likely that the forks have been reconciled and that one of these transactions will be rejected along with the rejected fork. </p>

<p>So, if double spending occurs exactly one of three things will have happened :</p>

<pre><code>1. You will have the bitcoins (even though they were promised to someone else)
2. Someone else will have the bitcoins (even though they were promised to you)
3. The original owner keeps the bitcoins.
</code></pre>

<p>Since you're not dealing with transactions that occur in real time, you only need to worry about whether or not you receive your bitcoins. After a number of confirmation, you can be confident that there was no double spend detected. </p>

<p>You noted that you wanted to identify suspicious transactions using the bitcoind API, but as mentioned before, there no way to identify a transaction as being inherently suspicious. If money shows up at your bitcoin address from a sender and you want to be confident that the transactions won't somehow disappear from the blockchain later, you could check the for forks in the block chain that might contain transactions with the same inputs, but simply waiting 6 confirmations, as you're already doing, is more than enough. If you don't get your coins, just let the customer know, and if the customer didn't double spend, he or she can just resend the payment. Essentially @Nate-Eldredge is right.</p>

CC BY-SA 3.0
2016-09-07T12:50:31.433Z
"if two transactions spending the same input(s) happen in the same block, both will be rejected." ←This might have been true in the past, but I doubt that this still holds. It seems to me that this answer is outdated.
Murch
CC BY-SA 3.0
2016-09-13T00:14:24.967Z
Honestly, I wasn't entirely sure if that was true when I wrote it, but it's entirely up to the client how to handle what happens when the same inputs occur in the same block. It would be advantageous for the client to continue with whichever transaction is most lucrative for them as a miner, but provided that the client only attempts to post valid blocks, the question lies outside of the bitcoin protocol.
John Henry
CC BY-SA 3.0
2017-01-27T15:48:44.357Z
If the bitcoins don't show up, it would be nice to know whether or not they've been double spent instead of simply wating for a timeout, so the vendor can take immediate action. The question has not been answered...
Gabriel
CC BY-SA 3.0
2017-02-13T15:58:59.710Z
@Gabriel in this case, the right thing to do is to wait for the next block, that is, 1 confirmation. If the bitcoins do not show up by the next block, the the vendor can take immediate action. In fact, the vendor should wait for the first confirmation before taking any action at all to be safe. By very nature of the system, this question will never be solved for zero confirmations.
John Henry
CC BY-SA 3.0
2017-02-13T17:29:33.280Z
Another tx appearing on the network with the same utxo as input can be detected before the next block. Or not?
Gabriel
CC BY-SA 3.0
2017-02-13T18:11:55.737Z
While there isn't a "suspicious transaction," there certainly are spammy ones.
Geremia
CC BY-SA 3.0
2017-02-13T20:54:03.140Z
@Gabriel I'm not sure if I understand your question -- in order to create the block one must confirm the transaction and in confirming this transaction, one prevents any other uses of the utxo -- that is, the unspent transaction becomes spent when the block is created. If there are two different transactions in the network with the same utxo, at least one of them will be rejected. Double spending is only an issue before the transaction is confirmed. Another tx appearing on the network with the same utxo as input will not be allowed into the next block.
John Henry
CC BY-SA 3.0
2017-02-13T21:07:44.073Z
To expand upon that last comment, there is still a degree uncertainty because it may take a while for parts of the network to be consistent. The mechanisms for achieving consistency allows for different blocks with the same utxos in different transactions to exist _temporarily_, but as the blockchain is eventually consistent, these blocks will be rejected. If the vendor has a reasonably good connection to the rest of the network, he or she can usually be confident that by the first confirmation that transition will not be rejected, but with each confirmation this confidence grows.
John Henry
CC BY-SA 3.0
2017-02-15T13:19:44.603Z
The original question was `How do I detect a double-spend?`...`on 0 confirms`. Well, to detect a double spend attack you have to check the network for additional tx with the same utxos, which can enter the pool before a block is confirmed with any of those concurrent tx. I'm not sure if 2 tx with the same utxo can enter the same pool or if there's gonna be concurrency between miners there, and i'm not sure if that can be detected with bitcoin core as asked, either. But blockcypher seems to be able to do it somehow.
Gabriel
CC BY-SA 3.0
2013-09-18T00:05:41.027Z
2014-04-30T12:38:13.173Z
2014-04-30T12:38:13.173Z
John Henry
<p>As a vendor, how do you detect a double-spend? I'm happy to tell end-users that I'm proceeding with a transaction on 0 confirms, simply assuming everything is fine. I'm selling physical goods and so I don't ship them until I actually have 6 confirmations. I only alert the customer if I actually discover a problem. But I still need to have a way to detect if a transaction is stuck vs a malicious double-spend. </p>

<p>At what point does a transaction become suspicious? Besides manually looking up transactions on blockchain.org, how do you know a transaction is a double-spend? Monitoring all transactions happening on the network in order to match transaction inputs (as does blockchain.org) seems excessive. I'm looking for a solution I can implement using the bitcoind API.</p>

CC BY-SA 3.0
2013-09-17T23:04:30.850Z
Why do you care? If the transaction doesn't confirm, for whatever reason, then you can't spend the coins, and you need to get the customer to pay again.
Nate Eldredge
<bitcoind><doublespend>
How do I detect a double-spend?
Derek Hans
# How do I detect a double-spend?

(Asked by: username_0 on 2013-09-17)

As a vendor, how do you detect a double-spend? I'm happy to tell end-users that I'm proceeding with a transaction on 0 confirms, simply assuming everything is fine. I'm selling physical goods and so I don't ship them until I actually have 6 confirmations. I only alert the customer if I actually discover a problem. But I still need to have a way to detect if a transaction is stuck vs a malicious double-spend.

At what point does a transaction become suspicious? Besides manually looking up transactions on blockchain.org, how do you know a transaction is a double-spend? Monitoring all transactions happening on the network in order to match transaction inputs (as does blockchain.org) seems excessive. I'm looking for a solution I can implement using the bitcoind API.

**Tags:** bitcoind, doublespend

> **Comments:**
> **username_1**: Why do you care? If the transaction doesn't confirm, for whatever reason, then you can't spend the coins, and you need to get the customer to pay again.  

---

## 2 answers

### Answer by username_4 on 2013-09-18. Score: 13 | Accepted answer

Essentially, there is no such thing as a "suspicous transaction" and bitcoin is already set up to work in the way that you want.

Double spending is handled like this -- if two transactions spending the same input(s) happen in the same block, both will be rejected. If one transaction makes it into a block before the other, the first one will be accepted and the second will be rejected.

Now, if two transactions entered the network simultaneously, but at different endpoint, by the time the next block is mined it's likely that they would have made it into the same block and thus be simultaneously rejected. It's also possible that a block is mined containing one transaction, and all subsequent blocks containing the other transaction will simply be rejected. The third and least likely scenario is that two blocks are mined simultaneously -- each containing one of the competing transactions -- and this would cause a fork in the blockchain. However, this is the purpose of having confirmations, and by the time you reach 6, it's extremely likely that the forks have been reconciled and that one of these transactions will be rejected along with the rejected fork.

So, if double spending occurs exactly one of three things will have happened :

```
1. You will have the bitcoins (even though they were promised to someone else)
2. Someone else will have the bitcoins (even though they were promised to you)
3. The original owner keeps the bitcoins.

```

Since you're not dealing with transactions that occur in real time, you only need to worry about whether or not you receive your bitcoins. After a number of confirmation, you can be confident that there was no double spend detected.

You noted that you wanted to identify suspicious transactions using the bitcoind API, but as mentioned before, there no way to identify a transaction as being inherently suspicious. If money shows up at your bitcoin address from a sender and you want to be confident that the transactions won't somehow disappear from the blockchain later, you could check the for forks in the block chain that might contain transactions with the same inputs, but simply waiting 6 confirmations, as you're already doing, is more than enough. If you don't get your coins, just let the customer know, and if the customer didn't double spend, he or she can just resend the payment. Essentially @username_1-username_1 is right.

> **Comments:**
> **username_5**: "if two transactions spending the same input(s) happen in the same block, both will be rejected." ←This might have been true in the past, but I doubt that this still holds. It seems to me that this answer is outdated.  
> **username_4**: Honestly, I wasn't entirely sure if that was true when I wrote it, but it's entirely up to the client how to handle what happens when the same inputs occur in the same block. It would be advantageous for the client to continue with whichever transaction is most lucrative for them as a miner, but provided that the client only attempts to post valid blocks, the question lies outside of the bitcoin protocol.  
> **username_2**: If the bitcoins don't show up, it would be nice to know whether or not they've been double spent instead of simply wating for a timeout, so the vendor can take immediate action. The question has not been answered...  
> **username_4**: @username_2 in this case, the right thing to do is to wait for the next block, that is, 1 confirmation. If the bitcoins do not show up by the next block, the the vendor can take immediate action. In fact, the vendor should wait for the first confirmation before taking any action at all to be safe. By very nature of the system, this question will never be solved for zero confirmations.  
> **username_2**: Another tx appearing on the network with the same utxo as input can be detected before the next block. Or not?  
> **username_6**: While there isn't a "suspicious transaction," there certainly are spammy ones.  
> **username_4**: @username_2 I'm not sure if I understand your question -- in order to create the block one must confirm the transaction and in confirming this transaction, one prevents any other uses of the utxo -- that is, the unspent transaction becomes spent when the block is created. If there are two different transactions in the network with the same utxo, at least one of them will be rejected. Double spending is only an issue before the transaction is confirmed. Another tx appearing on the network with the same utxo as input will not be allowed into the next block.  
> **username_4**: To expand upon that last comment, there is still a degree uncertainty because it may take a while for parts of the network to be consistent. The mechanisms for achieving consistency allows for different blocks with the same utxos in different transactions to exist _temporarily_, but as the blockchain is eventually consistent, these blocks will be rejected. If the vendor has a reasonably good connection to the rest of the network, he or she can usually be confident that by the first confirmation that transition will not be rejected, but with each confirmation this confidence grows.  
> **username_2**: The original question was `How do I detect a double-spend?`...`on 0 confirms`. Well, to detect a double spend attack you have to check the network for additional tx with the same utxos, which can enter the pool before a block is confirmed with any of those concurrent tx. I'm not sure if 2 tx with the same utxo can enter the same pool or if there's gonna be concurrency between miners there, and i'm not sure if that can be detected with bitcoin core as asked, either. But blockcypher seems to be able to do it somehow.  

---

### Answer by username_2 on 2017-02-13. Score: 2

You may use an external service like [blockcypher's confidence factor](https://www.blockcypher.com/dev/bitcoin/#confidence-factor) to have an idea of whether or not a double spent attack will be performed. It seems to base its evaluation on the number of nodes a transaction has reached and its mining fee.

A transaction is not guaranteed to be present in the next block depending on the fees of the transactions present in the pool and the fee of the transaction. So the delay may be long before confirmation. Using such heuristics may prove helpful to shorten your business process.

> **Comments:**
> **username_3**: 'Well, to detect a double spend attack you have to check the network for additional tx with the same utxos, which can enter the pool before a block is confirmed with any of those concurrent tx.'  <- This comment by @username_2 is acutally the correct answer. The checked answer goes on telling stories without  addressing the core question asked  

---

