Skip to content

Probabilistic Finality

Bitcoin's whitepaper includes an actual formula for exactly how confident you should be that a transaction won't be reversed, as a function of how many blocks have been mined on top of it and how much computational power an attacker might control. This chapter works through that formula directly, with verified numbers, rather than leaving "wait for confirmations" as vague advice.

The setup

Recall from Finality that Bitcoin offers probabilistic, not deterministic, finality: the deeper a block is buried under subsequent blocks, the less likely it becomes that a dishonest actor could ever produce an alternative chain that overtakes it. The Bitcoin whitepaper's Section 11 models this precisely as a race between the honest chain and an attacker's private chain, and computes the probability the attacker ever catches up.

The model

Let q be the fraction of total network hash power controlled by an attacker (so p = 1 - q is the honest network's share), and let z be the number of blocks mined on top of the transaction in question (its confirmation count). The attacker is assumed to be mining a competing, secret chain starting from the block before the transaction, hoping to eventually produce a longer chain and force the network to reorganize away from the honest chain, reversing the transaction.

The whitepaper models the attacker's chances using a Poisson distribution (approximating the number of blocks the attacker manages to mine in the time it takes the honest chain to extend by z blocks) combined with a Gambler's Ruin calculation (the classic probability-theory problem of a random walk with a bias, applied here to whether the attacker's block count can ever catch up to the honest chain's). The resulting formula, given directly in the whitepaper:

p = probability the honest network finds the next block
q = probability the attacker finds the next block
qz = probability the attacker ever catches up from z blocks behind

λ = z(q/p)

P(catch up) = 1 - Σ (k=0 to z) [ (λ^k · e^-λ / k!) · (1 - (q/p)^(z-k)) ]

Example: computing it directly

function factorial(n: number): number {
  let result = 1;
  for (let i = 2; i <= n; i++) result *= i;
  return result;
}

function attackerSuccessProbability(q: number, z: number): number {
  const p = 1 - q;
  const lambda = z * (q / p);
  let total = 1.0;
  for (let k = 0; k <= z; k++) {
    const poisson = (Math.exp(-lambda) * Math.pow(lambda, k)) / factorial(k);
    total -= poisson * (1 - Math.pow(q / p, z - k));
  }
  return total;
}

for (const z of [1, 2, 6, 10]) {
  console.log(`q=0.10, z=${z}: P(reversal) = ${attackerSuccessProbability(0.1, z)}`);
}

Verified output from running this exact code (matches the whitepaper's own published table):

q=0.10, z=1:  P(reversal) = 0.20458727394278242
q=0.10, z=2:  P(reversal) = 0.05097789283933862
q=0.10, z=6:  P(reversal) = 0.00024280274536282221
q=0.10, z=10: P(reversal) = 0.0000012414021748015377

What the numbers actually say

The table below extends this same computation across several attacker hash-power shares, verified directly by running the code above with different q values:

Confirmations (z) q = 10% q = 30% q = 45%
1 20.5% 62.8% 92.0%
2 5.1% 44.6% 87.8%
6 0.024% 13.2% 76.6%
10 0.00012% 4.2% 68.5%
20 ~0% 0.25% 53.7%

Two things stand out. First, at a modest attacker share (10% of hash power, already a very large, expensive amount of real mining hardware to control), confidence grows extremely fast with confirmations: by 6 confirmations, the reversal probability has fallen below one in four thousand, and by 10 confirmations it's below one in a million. This is why "6 confirmations" (roughly an hour, at Bitcoin's ~10-minute average block time, see Block Time) became a widely used informal standard for considering a Bitcoin payment settled for most practical purposes, and why exchanges historically required more confirmations for larger deposits.

Second, and just as important: against an attacker with close to 50% of network hash power, no number of confirmations makes the reversal probability negligible. At q = 45%, even 20 confirmations still leaves over a 50% chance the attacker eventually catches up, because the attacker's mining power is so close to the honest network's that the race stays close indefinitely. This is the mathematical content behind the term "51% attack" (see 51% Attacks): the entire security model assumes the attacker's share stays meaningfully, not just marginally, below half.

Under the hood: why waiting helps

Intuitively, every additional confirmation is another round the attacker's private chain has to keep pace with or overtake, and because the attacker has strictly less hash power than the honest network (by assumption. This whole model breaks down once an attacker actually exceeds 50%), each additional round is, on average, another round the attacker falls further behind rather than catching up. The Poisson term accounts for the real-world randomness in exactly how many blocks each side finds in a given stretch of time, rather than assuming a perfectly steady, deterministic pace.

Tradeoffs

Choosing how many confirmations to wait for is a direct, quantifiable risk decision, not an arbitrary convention, a transaction worth $10 and a transaction worth $10 million warrant different confirmation thresholds given the same underlying probability curve, which is exactly why the "right" number of confirmations depends on the value at risk and the discloser's assumption about realistic attacker hash-power share, not a single universal rule.

Common misconceptions

Zero confirmations does not mean zero security, but it means very little security against a determined double-spend attempt, an unconfirmed transaction sitting in the mempool can, in principle, be replaced by a conflicting transaction before it's mined (see Replace-by-Fee), which is why merchants accepting instant, unconfirmed payments for high-value goods carry real, documented risk.

More confirmations do not reduce the probability to exactly zero at any finite number, as the table above shows directly. The model only produces vanishingly small, not literally zero, probabilities, which is the precise meaning of "probabilistic" in this chapter's title.

Further reading


← Previous: Finality · Back to Distributed Systems · Next: What Is a Blockchain? →