Bitcoin confirmations: what becomes harder to reverse

A Bitcoin payment with one confirmation has crossed a meaningful threshold: a block in the chain recognized by the observing node contains it. That is stronger evidence than a wallet showing that the transaction was broadcast. It is not an irreversible receipt, and it does not certify the person receiving the money.

The useful question is what would have to change for that payment to disappear from the accepted history. Confirmations help answer that question. They cannot answer every question involved in settlement.

Count blocks, then identify the chain

The containing block provides the first confirmation. Each subsequent block added above it adds another. If a transaction appears at height H and the current tip is height H + 4, it has five confirmations, provided both blocks belong to the same active chain. The Bitcoin payment-processing guide distinguishes this from an unconfirmed transaction, which has not yet been included.

A confirmation count is therefore an observation about a particular chain at a particular moment. An explorer, wallet service and independently operated node may temporarily report different views. A screenshot without the transaction identifier, containing block and observation time is incomplete evidence.

Bitcoin Core's transaction reference exposes the confirmation count and containing block hash separately. It also distinguishes conflicts. Those fields are useful precisely because a transaction's status can change; the number is not a certificate issued once and kept forever.

Reorganizations replace part of the history

Two miners can produce competing valid blocks before either learns about the other. Nodes may initially follow different tips. When a stronger valid branch emerges, nodes following the other branch change their active history. That replacement is a chain reorganization.

Bitcoin chooses between valid branches using accumulated proof of work. The shorthand “longest chain” can obscure this: block count alone is not the general selection rule. The blockchain guide explains competing branches and the work needed to recreate them. A branch containing invalid transactions does not become acceptable merely because someone expended substantial hashing effort on it.

A transaction in a displaced block may also exist in the replacement branch. If it does not, its earlier confirmation count no longer describes the accepted history. Whether it can subsequently confirm depends on whether it remains valid, including whether its inputs were spent by a conflicting transaction.

More depth is evidence, not a universal guarantee

Reversing a deeper payment requires overcoming more accumulated work. The Bitcoin white paper's attack analysis models an attacker racing the honest chain. Its results depend on assumptions about the attacker's share of hashing power and the progress of that race. They are not a live probability reading for an individual payment.

This is why “six confirmations is safe” needs qualification. A familiar operational threshold is not a protocol guarantee. A receiver deciding when to release something irreversible has to consider the amount at risk, its ability to absorb a reversal and any abnormal network conditions. The payment-processing guide itself describes the familiar threshold as partly arbitrary and discusses circumstances requiring additional risk analysis.

Nor does a confirmation count specify an exact waiting time. Blocks arrive irregularly. A policy expressed in blocks and a deadline expressed in minutes answer different questions.

A worksheet for reading a settlement claim

These are analytical prompts, not a prescribed confirmation policy. Bitcoin Core's chain-information reference separates validated height, known headers, synchronization indicators and total chainwork. Checking context matters more than reading a large number in isolation.

Inclusion does not settle every obligation

Bitcoin validation does not establish that an address belongs to the intended counterparty, that a custodian will credit an account, or that a customer can withdraw from that custodian. Those questions need separate evidence about custody and control of customer assets.

Likewise, the work of selecting inputs and paying for inclusion belongs to the earlier explanation of Bitcoin transaction fees and change. Here the distinction is what happens after inclusion: confidence in an accepted history increases, while the receiver still needs its own explicit acceptance policy.