Probabilistic Finality

What Is Probabilistic Finality?

Probabilistic finality is a property of blockchain systems where a confirmed transaction becomes increasingly difficult to reverse with each subsequent block, but never reaches absolute irreversibility. Rather than a binary switch from "pending" to "final," security accumulates gradually: each new block stacked on top of the block containing the transaction raises the cost of undoing it by an exponential factor.

Bitcoin is the canonical example of probabilistic finality. Its proof-of-work consensus mechanism relies on the longest-chain rule: miners build on the chain with the most accumulated work, and reversing a confirmed transaction requires an attacker to re-mine every block from the target transaction forward while outpacing the honest network. The energy cost of this attack grows exponentially with each confirmation, making deep reversals economically infeasible even though they remain theoretically possible.

How It Works

Understanding probabilistic finality requires following the lifecycle of a Bitcoin transaction through the lens of an attacker. After a transaction is included in a block, an adversary attempting a double-spend must build a secret alternative chain that excludes the target transaction and grow it longer than the honest chain. The math that governs this race was laid out in Section 11 of the Bitcoin whitepaper.

The Attacker's Race

The scenario works as follows:

1. A merchant accepts a payment included in block N
2. The honest network continues mining blocks N+1, N+2, N+3, and so on
3. An attacker secretly mines an alternative chain starting from block N-1, excluding the payment transaction
4. If the attacker's chain ever surpasses the honest chain in length, they broadcast it, triggering a chain reorganization that erases the original payment

The key variable is q: the fraction of total network hashrate controlled by the attacker. If q < 0.5, the attacker's probability of catching up diminishes exponentially with each block the honest network adds. If q ≥ 0.5, the attacker succeeds with certainty: this is the 51% attack scenario.

Satoshi's Mathematical Model

Nakamoto modeled the attacker's race as a Gambler's Ruin problem. The probability that an attacker with hashrate fraction q ever catches up from z blocks behind is:

P_catch_up = (q / p)^z    where p = 1 - q

For q = 0.1 and z = 6:
P = (0.1 / 0.9)^6 ≈ 0.0000017

The whitepaper refines this using a Poisson distribution to account for the blocks the attacker may have already mined in secret while the honest chain grows. The attacker's expected secret blocks follow a Poisson process with parameter λ = z × (q / p):

P(z) = 1 - SUM(k=0..z) [
  (lambda^k * e^(-lambda)) / k!
  * (1 - (q/p)^(z-k))
]

The whitepaper included C code to compute this:

double AttackerSuccessProbability(double q, int z) {
  double p = 1.0 - q;
  double lambda = z * (q / p);
  double sum = 1.0;
  int i, k;
  for (k = 0; k <= z; k++) {
    double poisson = exp(-lambda);
    for (i = 1; i <= k; i++)
      poisson *= lambda / i;
    sum -= poisson * (1 - pow(q/p, z - k));
  }
  return sum;
}

In 2018, mathematicians Grunspan and Perez-Marco proved that Nakamoto's Poisson approximation is slightly optimistic. The exact closed-form solution uses the Regularized Incomplete Beta Function, meaning the true attack probability is marginally higher than the whitepaper's estimates.

Confirmation Probabilities

Using Nakamoto's formula for an attacker with 10% of hashrate (q = 0.1):

Each additional confirmation roughly divides the attack probability by four. By six confirmations, the chance of a successful double-spend is approximately 1 in 4,118.

Why Six Confirmations?

The convention of waiting for six block confirmations traces directly to the Bitcoin whitepaper. Nakamoto drew a practical security threshold at a probability below 0.1% (1 in 1,000) and computed how many confirmations this required for various attacker hashrates:

For a 10% attacker, five confirmations barely cross the 0.1% threshold. Six confirmations provide a comfortable margin. The original Bitcoin Core client reinforced this convention by labeling transactions as "unconfirmed" until six blocks had passed, and the number solidified through community practice and exchange adoption.

The critical assumption underlying this convention is that an attacker controls no more than 10% of hashrate. Modern mining pool concentration has shifted this calculus: with individual pools occasionally exceeding 30% of hashrate, achieving the same 0.1% security level requires significantly more confirmations. For high-value transactions, some analysts now recommend waiting for 20 or more confirmations.

Use Cases

When Fewer Confirmations Are Acceptable

Not every transaction needs six confirmations. The appropriate number depends on the value at risk and the cost of reversal:

• Zero-confirmation (0-conf) transactions are used for small in-person purchases where the item value is less than the cost of mounting an attack. Payment processors may accept 0-conf with additional safeguards like monitoring the mempool for conflicting transactions. For more detail, see the zero-confirmation explainer.
• One to three confirmations are common for mid-value transactions at exchanges. Many major exchanges accept Bitcoin deposits after two to four confirmations, balancing user experience against security.
• Lightning Network and other Layer 2 protocols use channel funding transactions that typically require three to six confirmations before the channel becomes active.

When More Confirmations Are Required

• Large exchange deposits (hundreds of thousands of dollars or more) may require 10 or more confirmations
• Institutional custody solutions often enforce custom confirmation thresholds scaled to transaction value
• Altcoins with lower hashrate are far more vulnerable to reorganization attacks. After multiple 51% attacks on Ethereum Classic, some exchanges required thousands of confirmations for ETC deposits

Probabilistic vs. Deterministic Finality

Not all blockchains use probabilistic finality. BFT-based consensus mechanisms achieve deterministic finality, where a transaction is guaranteed irreversible once a protocol-defined threshold is met. Understanding the tradeoffs between these models is essential when comparing payment finality across blockchains.

Bitcoin: Probabilistic

• Finality grows asymptotically: each block adds security but never reaches absolute certainty
• Time to practical finality: approximately 60 minutes (6 confirmations at ~10-minute block times)
• Reversal requires outpacing the honest chain with raw computational power: an energy-intensive physical attack
• The chain never halts: blocks continue to be produced regardless of network partitions, though confirmations during a partition may be less reliable

Tendermint / CometBFT: Deterministic

• A block is final the instant more than two-thirds of validator voting power commits to it
• Time to finality: typically one to seven seconds
• No subsequent valid chain can contradict a finalized block
• Tradeoff: if more than one-third of validators go offline or act maliciously, the chain halts entirely rather than producing potentially reversible blocks. The protocol sacrifices liveness for safety

Ethereum Post-Merge: Hybrid

• Ethereum uses a two-layer approach: the LMD-GHOST fork-choice rule provides probabilistic confirmation slot-by-slot, while the Casper FFG overlay periodically finalizes checkpoint blocks
• Deterministic finality arrives after two epochs (approximately 12.8 minutes)
• Reverting a finalized Ethereum block requires burning more than one-third of all staked ETH: an economic rather than computational barrier

Why It Matters

Probabilistic finality has direct implications for anyone building payment systems or settlement infrastructure on Bitcoin. Merchants, exchanges, and payment processors must calibrate confirmation requirements against transaction value: too few confirmations expose them to double-spend risk, while too many create unacceptable delays for users.

This tension is one of the core motivations behind Layer 2 solutions like the Lightning Network and Spark. By moving transactions off the base layer, these protocols offer instant settlement without waiting for on-chain confirmations. The underlying channel or protocol state can always be settled back to Layer 1 when needed, inheriting Bitcoin's probabilistic finality guarantees for the settlement transaction itself.

Understanding probabilistic finality also informs how the Bitcoin transaction lifecycle works end-to-end: from broadcast through mempool inclusion, initial confirmation, and the gradual accumulation of security with each subsequent block.

Risks and Considerations

Mining Concentration

The six-confirmation convention assumed an attacker with at most 10% of hashrate. Modern mining pool concentration has changed the threat model. Individual pools have at times exceeded 30% of total hashrate, meaning the same level of security that six confirmations once provided now requires significantly more. High-value transactions should calibrate confirmation requirements to current hashrate distribution, not historical conventions.

Chain Reorganizations

Even without malicious intent, natural chain reorganizations occur when two miners find valid blocks near-simultaneously. Single-block reorgs are routine (happening roughly once every few weeks on Bitcoin). Deeper reorgs are exponentially rarer but do occur: Bitcoin experienced a two-block reorganization in March 2026 when two major pools found blocks within seconds of each other. These events are not attacks but natural consequences of probabilistic finality.

The Finality Gap

The time between transaction broadcast and practical finality (60 minutes for six confirmations) creates a window of uncertainty. During this period, the transaction is confirmed but not deeply settled. This gap drives demand for Layer 2 solutions that can provide faster settlement for everyday transactions while reserving on-chain settlement for high-value or dispute scenarios.

No Absolute Guarantee

By definition, probabilistic finality never reaches 100%. A sufficiently funded and motivated attacker with enough hashrate could, in theory, reverse even deeply confirmed transactions. In practice, the cost of such an attack on Bitcoin (requiring billions of dollars in mining hardware and electricity) makes it infeasible for any plausible adversary, but the theoretical possibility distinguishes it from protocols with deterministic finality where reversal is not merely expensive but cryptographically impossible under honest-majority assumptions.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.