Confirmations and settlement, and why six is a convention

Bitcoin does not have finality in the sense that a court judgment is final. There is no point at which the protocol declares a transaction irreversible. Instead, the probability that a transaction will be reversed falls as blocks are added on top of it, and it falls steeply. The white paper frames this as a race between an attacker trying to catch up and the honest network extending the chain, and it shows that the attacker's chance of success decays exponentially with depth.

That decay is why the practical answer to "when is it safe?" is a number of blocks rather than a moment in time. The number is a judgement about how much risk a counterparty is willing to carry, and it depends on the value at stake. A coffee purchase and a property transfer do not warrant the same patience. The protocol supplies the mechanism; the parties supply the threshold.

It is worth being precise about what the probability depends on. It depends on the attacker's share of total hash power relative to the honest network's, and on how far behind the attacker starts. An attacker with a small share of hash power needs an implausible run of luck to overtake even a one-block lead. An attacker with a large share needs much less. This is why the security of a confirmation is a statement about the distribution of mining power, not about the transaction itself.

A reorganisation, or reorg, happens when a node learns of a chain with more accumulated work than the one it currently follows. The node switches to the heavier chain, and any blocks that were on the abandoned branch are no longer part of the canonical history. If those blocks contained transactions that are not also in the new chain, those transactions return to the mempool as unconfirmed.

Shallow reorgs of one or two blocks are a normal part of how the network resolves competing blocks. Two miners can find valid blocks at nearly the same height, and the network briefly disagrees about which is canonical until the next block settles the matter. Deeper reorgs are rare, and the depth of a reorg is a direct measure of how much work was discarded. A reorg that rewrites six blocks means six blocks of proof-of-work were abandoned, which is an expensive event and a strong signal that something unusual has happened.

The practical implication for a recipient is that a confirmation count is a bet on reorg depth. If a counterparty accepts a payment after one confirmation, they are betting that no reorg deeper than one block will occur before they have exchanged whatever the payment bought. For small, fast transactions that bet is usually fine. For large ones it is not, and the standard practice is to wait longer.

Six confirmations is the most widely quoted number in Bitcoin, and it is not in the protocol. No consensus rule counts to six. No node refuses to relay a transaction because it is five blocks deep. The number comes from the white paper's analysis of the probability that an attacker catches up, evaluated at a particular assumed share of hash power, and it was adopted by exchanges and payment processors as a workable default. It has stuck because it is a reasonable compromise between safety and speed for the transaction sizes those businesses handle.

The convention is worth understanding as a convention rather than a rule, because it is routinely applied where it does not fit. A high-value settlement may reasonably want more than six confirmations. A small retail payment may reasonably want fewer, and many point-of-sale systems accept zero-confirmation transactions for low values on the basis that the risk is bounded and the merchant would rather complete the sale. Neither choice violates anything. The protocol does not care.

What the protocol does provide is the raw material for the judgement: a chain of blocks, each carrying proof-of-work, each extending the one before it. A reader who wants to reason about settlement should treat the confirmation count as an input to a risk decision rather than a switch that flips from unsafe to safe. The transaction lifecycle page covers how a transaction reaches a block in the first place, and the transaction fees page explains why the wait before the first confirmation varies so much.