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.

  • 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. Commented Sep 17, 2013 at 23:04

2 Answers 2


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 @Nate-Eldredge is right.

  • 1
    "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
    Commented Sep 7, 2016 at 12:50
  • 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
    Commented Sep 13, 2016 at 0:14
  • 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
    Commented Jan 27, 2017 at 15:48
  • @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
    Commented Feb 13, 2017 at 15:58
  • 1
    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
    Commented Feb 15, 2017 at 13:19

You may use an external service like blockcypher's 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.

  • 1
    '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 Commented Jun 5, 2017 at 6:05

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.