On Zero Confirmation Transactions

This article is a response to a growing meme in the Bitcoin community that ‘zero confirmation transactions were never safe’ and therefore the core developers should change the code to make zero confirmation transactions totally unusable. Not only is this meme false, but the proposed code changes substantially reduce the utility of Bitcoin in the short run, and possibly the long run as well.

What are zero confirmation transactions?

Here’s a little refresher for those unfamiliar with how Bitcoin works. When someone sends you bitcoins, the transaction is broadcast to all the nodes in the Bitcoin network. The mining pools collect these new transactions and temporarily hold them in memory. At this point we say that transactions are “unconfirmed” or “pending” inclusion in Bitcoin’s ledger ― the blockchain. Approximately once every 10 minutes a mining pool collects these transactions from memory, organizes them into a block, and adds that block of transactions to the blockchain. This process repeats every 10 minutes on average.

We sometimes hear people say that Bitcoin transactions are irreversible. That’s not technically true, or at least not true of transactions that have been made recently. In the first number of minutes after a transaction is made, it can theoretically be reversed (or ‘double spent’) by the sender, assuming he has some technical ability. This means someone could pay you for some merchandise, then steal back the coins afterwards. The more time that passes, however, the more difficult it becomes to reverse a transaction. Typically we say that “unconfirmed” transactions are the easiest to reverse, while the deeper a transaction is in the blockchain, the more difficult it is to reverse. After a transaction is buried six or so blocks deep in the blockchain (about an hour), the probability of a successful double spend drops close to zero.

But why all the fuss about about unconfirmed transactions? While most Bitcoin users can afford to wait an hour for their payments to confirm, there are some business models which cannot. Retail is the most obvious example. Customers need to be able to pay the cashier and leave the store instantly. They can’t be required to wait around for 10 minutes or longer for their transaction to confirm. If retailers are unable to mitigate the risk of fraud when accepting unconfirmed transactions, then they simply wont accept Bitcoin.

How to double spend

Double spending an unconfirmed Bitcoin transaction is actually rather easy for people with the technical ability. The easiest way is to create two transactions which spend the same Bitcoins. The first transaction sends the coins to the merchant, while the second sends the coins back to yourself. The trick here is you need to make sure the merchant sees the legitimate transaction first and the double spend second (or preferably not at all), while ensuring the mining pools see the double spend first and the legitimate transaction second. Given how fast transactions propagate around the network, it’s tricky to get the timing correct, but assuming you do, the merchant will think he received a valid payment, while the miners will include double spend in their blocks. This can be done with a very high success rate and is probably responsible for almost all of the ‘zero confirmations transactions are trivially reversed’ meme.

Well not so fast

While we can indeed double spend unconfirmed transactions with a very high success rate, the merchant should be able to trivially detect most double spend attempts as they happen. Last year Gavin Andresen and Tom Harding wrote some patches for Bitcoin Core that would have relayed the first double spend attempt for each transaction around the network (double spends were not previously relayed and would not reliably propagate the network). With double spend relaying a retail point-of-sale terminal could have detected a double spend attempt and flagged the cashier to halt the transaction. The screen might read ‘payment declined’ and the customer asked for another form of payment. Should the original transaction actually confirm, the retailer could just refund it. The patches actually got merged into the codebase but, of course, the usual suspects bitched and moaned about ‘encouraging people to rely on zero confirmation transactions’ and the code was removed.

So basically a patch that could have prevented people from fraud was removed. And what’s rich is that some of the same people who blocked the double spend relaying cite the above attack as a reason why no one should use zero confirmation transactions. Nevertheless, companies were able to accomplish the same thing by just maintaining a large number of network connections, which is more of a burden on the network than double spend relaying would have been.

Now you will often hear straw man arguments like “only the blockchain can prevent double spends, that’s why we have it”. Of course, but notice that we aren’t talking about preventing double spends, only detecting them. And in the six years bitcoin has been going, this risk mitigation strategy has worked fairly well. Most bitcoin purchases are done through payment processors who accept zero confirmation payments and the rate of fraud has been negligible.

This doesn’t mean every double spend attempt has been stopped, they haven’t. But we don’t need to stop 100% of double spends ― only enough to remain competitive with credit cards, which currently have fraud rates much higher than Bitcoin. As Shapshift.io CEO, Eric Voorhees put it:

We accept thousands of zero-conf transactions. We don’t need it to be impossible to double-spend, we just need to mitigate the risk sufficiently to where it can still make business sense. An occasional double-spend against us is worth the cost for the improved user experience.

It’s a straw man to suggest we think zero confirmation transactions are “100% safe”. They aren’t, but they don’t need to be to serve the purpose.


Given double spend detection, it becomes very difficult to successfully defraud a retailer. Ideally what you would like to do is broadcast the valid payment, leave the store with the merchandise, then broadcast the double spend. The problem you have is every miner (from the very beginning of Bitcoin through today) has been programmed to accept the first transaction it sees as valid and reject subsequent double spends. If you wait until you are in your car driving away with the merchandise to broadcast the double spend, all miners will reject it.

But here’s where things start to break down. While every miner is programmed to use this “first-seen” policy, technically there is nothing forcing them to do so. In theory, a miner could patch their code to implement some other policy and in practice some have.

Consider the case of the Eligius mining pool. The pool operator believes that certain types of transactions, such as gambling transactions, constitute “spam” and should be banned from the network. So he runs a patch that checks each transaction for payments to certain addresses and refuses to include those transactions in his pool’s blocks. His code refers to it as an “is notorious” check. And this is fine, he has every right abstain from including those transactions. If he doesn’t include them, the next miner will. But the way it’s implemented is his pool doesn’t just abstain from including them in blocks, but it deletes them from memory allowing double spends to take their place.

So a new attack would look like this: Create two transactions; One sending coins to the merchant with a second output sending a small amount of coins to a gambling service. Then create a normal double spend transaction. Send the first transaction to the merchant, walk out the store with the merchandise, then send the double spend to the Eligius pool. At the time of writing Eligius has about 3% of the hashing power. That means you have a 3% chance that Eligius will mine the next block containing your double spend. A 3% chance of success is still fairly low, but you can repeat this over and over again until it works.

As damning as this seems to zero confirmation transactions, this too is detectable. The sys admin in charge of the retailer’s POS software could just add his own “is notorious” check to incoming transactions and push the “payment declined” message to the register if such a transaction is detected. Problem solved.

Of course if you have to do this for every mining pool, it can be cumbersome, but it doesn’t mean that it wont work as a risk mitigation strategy. If you miss some change in miner policy, you will surely find out about it when someone exploits it, but at least that’s only a one-time score. This is mostly what happened to Voorhees’ ShapeShift earlier this year. Miners changed their policy in regards to transaction fees, deleting transactions with fees below a certain value, while ShapeShift continued to accept them.

The fact that ShapeShift failed to stay up-to-date with changes in miner policy, and paid a small price for doing so, is hardly evidence of unconfirmed transactions being ‘trivially double spent’ or ‘always unsafe’. Yet the opportunity was not missed to push that propaganda on everyone.


Up to this point we have been considering a network where all miners are using the “first-seen” policy or variations thereof. In such a network, we can detect double spends and thus prevent almost all fraud attempts as long as our code is up-to-date with the various differences in miner policy.

But opponents of zero confirmations transactions envision a dystopian world in which would-be fraudsters pay miners higher transaction fees to ignore the first-seen rule and include double spends in their blocks, essentially aiding in the fraud. In such a scheme, a thief could leave the store with the merchandise, then find a willing miner to help them defraud the merchant and replace the valid transaction with the double spend.

The theory goes that miners are rational profit-maximizers so why wouldn’t they accept higher fees if people are offering? Furthermore, people who hold this view believe that it is “inevitable” that miners will abandon the “first-seen” policy for “replace-by-fee” because, after all, this is basic game theory and economics.

But there are problems with this theory. The biggest of which is that Bitcoin has existed for six years so far and not a single miner has implemented this “inevitable” policy. There have been two attempts that I know of. The first was a mining pool called BitUndo which was run out of the Bitcoin community with pitchforks without a single miner joining the pool. The second was when Peter Todd convinced some horrifically confused Chinese miners to use his patch only to have them switch back hours later when they realized the mistake they made. Typically, only dogmatists cling to a theory in the face of overwhelming empirical evidence to the contrary.

So why haven’t miners rushed to adopt this “profit maximizing” policy? Well maybe one reason is that it isn’t actually profit maximizing. The theory outlined above seems to be unduly focused on short run profits and not the overall health of the bitcoin ecosystem which is necessary for maximizing long term profits over the life of their mining investments. Blowing up zero confirmation transactions to the point where retail stores stop accepting Bitcoin, while simultaneously enabling rampant fraud, hardly seems good for the value of your mining operation.

Furthermore, maybe miners (correctly) recognize that the only use case for the replace-by-fee policy is to defraud merchants and don’t want to take part in an activity is clearly immoral and likely also illegal. Now to clarify, there is a lesser form of replace-by-fee, called “first-seen-safe” which is useful for bumping transaction fees on transactions that get stuck, but does not allow double spending. The “full” replace-by-fee we are discussing here has no other purpose but to allow miners to accept fees in exchange for helping to defraud merchants.

You would think that this would be a policy that should be roundly denounced and discouraged at every turn; yet in the bizarro world of Bitcoin core development, we not only have developers supporting such a policy, but writing code and attempting to persuade miners to use it! I’ve even heard it argued that, if for no other reason, RBF should be adopted because it will teach people not to accept zero confirmation transactions since they are unsafe. This is the functional equivalent to slashing someone’s tires because there is a tiny percentage chance they will get into an accident if they drive. “Driving is unsafe!” It’s incredibly paternalistic and disingenuous.

Where are we at today?

Since previous core maintainer Gavin Andresen and Mike Hearn have now been purged from core development it seems the developers are hell bent on ramming through replace-by-fee.

An “opt-in” version has already been rammed through, without consensus, and with almost no discussion. The opt-in version only enables replace-by-fee on transactions containing a sequence number less than the maximum. Technically, retailers will be able to detect unconfirmed RBF transactions and reject them (making the fee bump part of it useless). So, at least in theory, the opt-in shouldn’t totally destroy zero confirmation transactions. But the intent is clear. The goal is to eventually eliminate the opt-in part, this patch is just to get the foot in the door.

Once zero confirmations transactions are totally destroyed, you will only be able to transact with a retailer by using one of the quasi-centralized, third-party solutions that these developers are hoping to profit from as a replacement. That is, if retailers still bother with Bitcoin by that point.

14 thoughts on “On Zero Confirmation Transactions

  1. Pingback: CryptoMashup » Bitcoin Bitcoin Core is headed towards full RBF and the death of 0-conf aka bitcoin as a settlement layer, but miners may want to rethink this.

  2. Excellent writeup. I’m a retailer that has accepted about 500k USD worth of 0-confirmation transactions and had no incidents of fraud due to just waiting a minute or two before processing. Sometimes it can be an hour between blocks and I didn’t want my customers to have to wait more than a minute or two for their gift cards.

    I’ll write in the RBF detection code but I’m very frustrated at the direction this is going.

    I’m also in the midst of writing a Bitcoin payment processor and this puts a hamper on a lot of the features I was planning on implementing.

  3. Pingback: [Ep.41] Bitheat. Alternative Bitcoin clients. Mycelium Gear & Crypto Threads. | AllCryptoCurrencies.com

  4. Pingback: Vanillacoin VNL is the elephant in the room | coincidental

  5. Pingback: NEWS: Bitheat. Alternative Bitcoin clients. Mycelium Gear & Crypto Threads. | Bitcoin News and Updates

  6. Pingback: Roger Ver Is Still Determined to Increase the Bitcoin Block Size Limit via a Hard Fork - Your Daily Satoshi

  7. Pingback: Altcoin News - AltcoinsNews Roger Ver Is Still Determined to Increase the Bitcoin Block Size Limit via a Hard Fork -

  8. Pingback: Roger Ver Is Still Determined to Increase the Bitcoin Block Size Limit via a Hard Fork | CoinGregate

  9. Pingback: Roger Ver Is Still Determined to Increase the Bitcoin Block Size Limit via a Hard Fork - Coinmonitor

  10. Pingback: Virtual Mining Bitcoin News » Roger Ver Is Still Determined to Increase the Bitcoin Block Size Limit via a Hard Fork

  11. Pingback: Roger Ver Is Still Determined to Increase the Bitcoin Block Size Limit via a Hard Fork | Bani-Digitali.ro

  12. Pingback: Real-life evidence of the breadown of Bitcoin's (BTC) security model. - Crypto News

  13. Pingback: Real-life evidence of the breadown of Bitcoin’s (BTC) security model. – ArticleZip.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s