5 min read

How Many Bitcoin Confirmations is Enough?

How safe is it to accept a bitcoin transaction after X confirmations? A deep dive into the math behind quantifying double-spend risk.
How Many Bitcoin Confirmations is Enough?

If you've been paying attention to Bitcoin for more than a few minutes, you're probably aware that it's dangerous to accept unconfirmed (AKA 0-conf) transactions. With zero confirmations, you as a receiver of BTC are vulnerable to the race attack, the Finney attack, as well as the 51% attack.

If you are patient enough to wait for at least one confirmation then you are no longer vulnerable to race attacks or Finney attacks. Now your only concern is 51% attacks. What's the rule of thumb for an acceptable number of confirmations?

1 confirmation: sufficient for small payments less than $1,000.

3 confirmations: for payments $1,000 - $10,000. Most exchanges require 3 confirmations for deposits.

6 confirmations: good for large payments between $10,000 - $1,000,000. Six is standard for most transactions to be considered secure.

10 confirmations: suggested for large payments greater than $1,000,000.

We've Got to Go Deeper

Naturally, since this is Bitcoin, it's not quite that simple. The rule of thumb for confirmations is based upon assumptions that we don't really talk about!

For example, the broadly suggested confirmation thresholds listed above are actually based on an attacker with 10% of the global hash rate. In such a case, 6 confirmations gives you a 99.99% assurance that the attacker can't rewrite that much history from the blockchain.

But these calculations (which can be found in the whitepaper) were performed long before the invention of mining pools and industrial mining operations. At the time it was reasonable to assume that it would be very difficult for someone to have over 10% of the global hashrate. Ever since 2011 there have been plenty of block-producing entities (pools) on the network that have amassed far more than 10% of the global hashrate. At time of writing, there are 5 such pools!

Quantifying Realtime Risk

Pages 6 & 7 of the bitcoin whitepaper outline the method by which you can calculate the risk of an attacker rewriting the blockchain after a given number of confirmations.

The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by 1, and the failure event is the attacker's chain being extended by one block, reducing the gap by 1. The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem. In layman's terms: the gambler (attacker) is expected to lose most of the time, thus the longer they play this game that has a negative expected value, the less likely they are to emerge as the winner.

Given our assumption that the attacker has less than 50% of the network hashrate, the probability of the attacker catching up drops exponentially as the number of blocks they have to catch up with increases. With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind. The attacker's potential progress itself is a Poisson distribution, since all mining is a Poisson process and thus successful outcomes follow this distribution.

To determine the probability that an attacker can rewrite the blockchain from z blocks ago, we multiply the Poisson density for each amount of progress the attacker could have made by the probability he could catch up from that point, where:

p = probability an honest miner finds the next block
q = probability the attacker finds the next block
z = how many blocks (confirmations) need to be reorganized
lambda = z * (q / p)
k = integer from 0 to z

This is not a fun formula to calculate by hand, so it seemed like a great candidate for an open source project...

Introducing the Confirmation Risk Calculator

I've created the following tool that will dynamically calculate the current chain reorganization risk based upon the mining pool with the highest hashrate estimate (from the trailing week of mined blocks.) You can, of course, override this parameter with any other hashrate percentage and desired number of confirmations to get a risk score.

Bitcoin Confirmation Risk Calculator
Calculate how safe it is to accept a bitcoin transaction after X confirmations.

Now it's easy to see that if we want 99.9% certainty that our transaction won't be double-spent, for an attacker with a given % of the network hashrate, the number of confirmations increases drastically as the attacker's hashrate approaches 50%.

% Attacker Global Hashrate # Confs for 99.9% Certainty
10 5
15 8
20 11
25 15
30 24
35 41
40 89
45 340

Why Should You Care?

At time of writing, Foundry has 36% of the global hashrate; that means if you're accepting payments after 3 confirmations there's a 49% chance that Foundry could still rewrite the chain to facilitate a double spend.

Source: https://www.blockchain.com/explorer/charts/pools

The 6 block confirmation rule of thumb to achieve 99.99% assurance a double spend can't happen (and assumes a 10% hashrate attacker) now requires 60 confirmations to achieve the same level of confidence.

As for the practicality of such an attack: pools are certainly disincentivized from performing attacks; they would likely lose a ton of business if they were to do so. And miners in general are long-term holders that are disinclined to harm folk's confidence in the system. However, a pool can still be a single point of failure; someone could exploit a vulnerability to hijack a pool for a short period of time. It's happened before, like this BGP attack that rerouted a bunch of mining pool traffic to mine coins for the attacker.

Final Thoughts

Bitcoin, for all its robustness and stability in some aspects, is quite volatile and dynamic in other aspects. It's important for folks who are receiving high-value payments on the Bitcoin blockchain to realize that they should adjust their risk assessment based upon the current state of the mining ecosystem.

To be clear, the above point about Foundry should not be construed as this being some sort of imminent / systemic threat to the integrity of the Bitcoin network. Over the past decade we have seen levels of miner centralization ebb and flow as a result of a multitude of factors. For example:

I remain optimistic that the incentives driving industrial Bitcoin miners are sound. They will continue to seek out sources of cheap / stranded / excess energy, and it is the very nature of energy that it is well-distributed around the world. Over the long term I expect we'll see the hashrate distribution across pools become less concentrated. There are also technology improvements such as Stratum V2 that remove power from pool operators and put it back in the hands of individual hashers.

Also: confirmations across networks are not at all comparable! Check out howmanyconfs.com to see how other Proof of Work networks stack up to Bitcoin.