How to minimize risk when accepting zero confirmation payments?



I'm trying to setup a way of accepting Bitcoin payments in real life situations, where waiting for confirmations is typically not an option. I understand this is never 100% risk free (especially with crap like around), I just want to minimize the risk.

I've got a Bitcoin Core wallet with a bunch of unused addresses. I show the customer an address, he sends the money, and now I can do a few things: (all automated, i.e. through some kind of application or script)

  1. Check if the (unconfirmed) transaction appears on my own node / in my wallet
  2. Check if the (unconfirmed) transaction appears on sites using online APIs like and
  3. Check if I don't see a similar transaction (from the same input address, but to another output address, i.e. a double spend attempt) on either my node or API sites.

If 1 or 2 are OK and 3 doesn't occur for e.g. five to ten seconds, how (un)certain is the transaction at this point?

I noticed that payment providers like bitpay and coinbase can sort of accept payments immediately, how do they tell legit transactions from double spend attempts?


Posted 2014-04-27T14:19:16.840

Reputation: 789

For selling a cup of coffee, a soda or sandwiches - I believe other coins (as Ripple, 42coin or even Dogecoin) would be more appropriate for this: I can very well see people waiting for up to 2 minutes, but no more, at which point your risk is enormously reduced. – Joe Pineda – 2014-04-29T02:18:35.437


I'm currently trying to solve the same problem with connecting to as many nodes as possible in order to detect a possible double spend in a few seconds. Just to correct your assumption a bit: 3.) a transaction coming from the same input address to a different output address does not necessarily mean double spend if it spends different TXOUTs. Therefore you should only look for transactions spending the same TXOUT, but sending it to a different address.

– knaperek – 2014-04-27T22:24:24.370

3@JoePineda Let's just picture that in detail for a moment: You are at your favorite coffee shop, in line to get a cup of coffee and donuts (or similar). Behind you there are five more people waiting. Everyone just wants to grab something and rush on to work. 10 minutes certainly are a no-go, but even two minutes standing there watching half a dozen people grab their stuff and go on with their morning are unacceptable. – Murch – 2014-05-02T06:19:14.250

1Good point! I myself am willing to wait up to about 2 minutes at the counter - once I'm in front of the clerk, that is. But am not willing to spend more than 3 minutes altogether, summing those in line plus at the clerk, and I guess most people wouldn't either :( – Joe Pineda – 2014-05-03T21:13:02.557

@JoePineda, 10 seconds is the threshold of tolerance. Don't forget that it's not just 10 secs/customer but an extra 10 secs/customer, in addition to the 20 seconds we already have to wait while the cashier scans the item. – Pacerier – 2014-05-23T16:26:21.193

@RocketNuts, What's wrong with BitUndo? – Pacerier – 2014-05-24T08:05:53.787

@Pacerier it includes in the block a transaction with higher fee, not the first one. That makes them a good processor for double spends. – jangorecki – 2015-08-29T10:35:06.230



From, here is what services like MyCelium and BitPay may be doing:

More specifically, with every additional second a larger percentage of active Bitcoin nodes will have heard the original transaction and everyone viewing the blockchain can be increasingly certain that the transaction will be mined in the next block and receive one confirmation, then two, and so on and so forth.

What this means is that any Bitcoin transaction can be accepted with zero confirmations with a mathematically derived confidence level some refer to as “Transaction Confidence.” This transaction confidence measure assures us that even if a double spend were attempted the original and correct transaction is already too heavily propagated to be overtaken.

But as you aptly noted, there is no 100% risk-free way of being able to do this if you don't trust the sender. That's why the blockchain exists in the first place.

One risk of relying on "transaction confidence" is that there's nothing in the network that prevents someone from submitting a double-spend transaction directly to the miners, without broadcasting it to the network as a whole, under the agreement that any blocks that those miners find should pick their secret one instead of the one they broadcast to the network. This is a risk no matter how much of the network sees the public transaction, which is one of the reasons why you can't have 100% confidence in a transaction that has never made it into a block.

In particular, if you accept a 0-confirmation transaction that spends inputs from other 0-confirmation transactions, the risk is much greater, because either the transaction directly to you or any of its 0-confirmation inputs could be double-spent, to your detriment.

Frankly, even 1-confirmation transactions aren't risk-free. Even under normal circumstances, blocks get orphaned, which could create a window for double-spending, because the winning branch may not resolve the transactions the way that the losing branch did.

If you're serious about trying to minimize the risks of accepting BTC in "real-life" (a.k.a., brick-and-mortar) situations where speed is important, I can't think of a better idea than going with a service like Coinbase (no affiliation). Those services operate on a scale where they can afford to eat losses from double-spends, which should be rare, so that you don't have to worry about it. Currently, they have an economic incentive to increase adoption of the currency by being very attractive to merchants who choose to do so.

Joe Amenta

Posted 2014-04-27T14:19:16.840

Reputation: 401

Thanks for the detailed answer. Are miners typically not normal nodes in the sense that they don't relay or propagate transactions to the rest of the network? I mean if I would deliberately send a 'secret' tx to a miner's node (hoping to get that included in the blockchain), wouldn't it get relayed to other nodes as well, thus allowing its presence to be detected on the network? – RocketNuts – 2014-04-27T16:15:27.080

That's an important distinction to make, and it's subtle. Yes, miners are typically running "normal" nodes, but remember that miners only typically do things to help the network because it furthers their own self-interest. If you have an arrangement with miners to pay them some cut of your double-spend gains, then it's to their advantage to keep your transactions secret until they hit the blockchain. They control the software that they're running, and it's open-source. Heck, miners already run modified node software. Eligius implements CPFP, which isn't in standard node software. – Joe Amenta – 2014-04-27T16:35:17.413

Would it be feasible to connect to such mining pools (or all major mining pools for that matter), just to see what transactions are supposed to be included? – RocketNuts – 2014-04-27T18:47:13.237

Not really. If miners are incentivized to secretly favor some transactions over others, then they have no reason to share that information with anyone other than the person who contracted them to include the double-spend transaction. Even if they did, you would have no reason to trust them. – Joe Amenta – 2014-04-27T19:26:49.247

Sure, but that would only apply to individual miners, right? Which generally have a very small chance of actually mining the next block, in which they're trying to include a secret tx (at the expense of a public tx not getting confirmed). But when checking the transaction data that is being mined by pools, I'd say this should be detectable...? Or is there a way to do pooled or distributed mining (i.e. have many people simultaneously trying to hash a list of transactions, including a secret tx) without actually disclosing the secret tx? – RocketNuts – 2014-04-27T19:51:16.560

That raises a good point. While pools generally act as just "one big miner" for most purposes, that's not necessarily true when it comes to keeping a particular transaction a secret. Without having looked into these protocols in too much detail, you can easily hide a transaction in the data used for stratum or the increasingly obsolete getwork protocols, but with getblocktemplate, it should be impossible for the pool to do this in secret (though individual miners can do this on their own) – Joe Amenta – 2014-04-28T09:19:48.530

let us continue this discussion in chat

– Joe Amenta – 2014-04-28T09:20:00.537

1@JoeAmenta, But delegating the task to a 3rd party is simply pushing the problem around the table. The question is still valid: How does the 3rd party minimize risk when he accepts zero confirmation payments? – Pacerier – 2014-05-23T16:30:28.113

@Pacerier, the third-party has a bunch of options at high volume, so long as it's not killing their business. If that party observes that an average 1% of all transacted volume is lost to double-spends, then they can start charging a flat 1% fee to recoup the losses. If a particular merchant proves to be problematic, then they can simply drop that merchant (or charge a higher fee if it's just the nature of the merchant's business). – Joe Amenta – 2014-05-24T00:08:10.850

@JoeAmenta, Good idea on "dynamic fees" there. – Pacerier – 2014-05-24T07:02:07.560

2It's important to note that Coinbase only gives you double-spend protection if you're using their paid "instant-exchange" service which immediately cashes out payments for fiat. If you're keeping the bitcoin in your Coinbase wallet, no such guarantee is provided. (Their documentation is not entirely clear on this, but I just got this clarification from a Coinbase support rep.) – Chris Martin – 2014-10-08T00:25:39.187

This answer should definitely link/mention the Have a Snack, Pay with Bitcoins document, google it – jangorecki – 2015-08-29T11:04:36.300


First of all and most important: do only business with people you trust. That does not mean that you have to have known them for a long period of time, but only that the person that is doing business with you is more likely to optimize his profit if he does not scam you.

I'm not sure about the odds of successfully launching a double spend attack after a x seconds wait, but what you can do is write some software that connects to some of the major mining pools and waits if your transaction (or a malicious double spend attempt transaction) shows up. It would be great if mining pools had a web API for checking which transactions are likely to get included in their next block, but unfortunately they don't. That means that you would have to program such application yourself (I do not know of any existing libraries with this functionality, but enlighten me if they exist).

Finally, you could always work with green addresses. If your partner agrees in trusting some third party, transactions can be cleared instantaneous.


Posted 2014-04-27T14:19:16.840

Reputation: 1 560

1Good suggestion about connecting to mining pools. Only doing business with people I trust, or green addresses, are not an option, I'm afraid. It's supposed to accept payment from random customers (i.e. complete strangers). – RocketNuts – 2014-04-27T15:26:10.073

Then there is no solution, except to connect to many nodes as possible, and especially to mining pools. Just connect as a dummy node and fetch the block they are working on. AFAIS there is no way the pool can cheat on you, if it is decentralized and open, like P2Pool. – Jori – 2014-04-28T11:19:59.810