A confirmation count measures work, not final settlement

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

What a confirmation actually counts

A confirmation is not a certificate; it is a count of blocks built on top of the one containing a transaction. The developer guide's payment processing chapter sets out a tiered view of risk: zero confirmation transactions should generally not be trusted without risk analysis, a single confirmation still leaves a transaction exposed because the most recent block gets replaced fairly often by accident, and the guide recommends that software handling high-value transactions should wait for at least six confirmations before treating a payment as accepted. Six is a threshold chosen for risk tolerance, not a value fixed by the protocol itself.

How a short reorganisation happens

The block chain chapter describes the underlying rule: normal peers always follow the most difficult chain to recreate and throw away stale blocks belonging to shorter forks, blocks it also calls orphans. Two valid blocks can be found at nearly the same time by different miners; each propagates to part of the network, and until a following block extends one branch further, nodes disagree about which block is current. Once one branch pulls ahead, the shorter branch is discarded and any transactions unique to it return to an unconfirmed state, needing to be re-included elsewhere. This is routine at a depth of one block, which is why the guide treats a single confirmation cautiously.

Why depth, not time, is what matters

The whitepaper's calculations section works through why depth compounds security: for an attacker controlling 30 per cent of network hashing power, its own table puts the probability of catching up and reversing ten confirmed blocks at just over 1 per cent, falling toward roughly six thousandths of one per cent by forty blocks, and the paper states that probability falls below 0.1 per cent only once the attacker needs to overturn 24 blocks. A reorganisation of a handful of blocks is a known, if uncommon, event; reversing a deeply buried transaction against an honest majority is a different order of difficulty, and the paper's own maths does not claim otherwise for a minority attacker.

Questions to carry forward

• Is a stated confirmation count the exchange's or custodian's own policy threshold, or a claim about protocol-level finality?
• Has the transaction in question already survived a visible short reorganisation, or is its current depth untested by one?
• Does an assumed attacker share of hashing power match what the source claiming safety at a given confirmation count actually modelled?

Confirmation depth is a proxy for accumulated, verifiable work, and the number that matters is chosen for the risk being carried, not handed down by the software.