How Confirmations Work and Why They Matter

The Concept

Once your transaction is included in a block, it has one confirmation. Every subsequent block mined on top of that one adds another confirmation — so a transaction with 6 confirmations means 6 blocks have been built on top of the block containing it, roughly an hour later given Bitcoin's ~10-minute average block time.

Confirmations matter because Bitcoin's security model relies on proof of work making history expensive to rewrite. To reverse a transaction buried under several blocks, an attacker would need to out-mine the entire rest of the network for that many blocks in a row — redoing the computational work of each block plus racing ahead of everyone else building new blocks in real time. The deeper a transaction is buried, the more total computational work (and real-world electricity cost) stands between it and any attempted reversal. This is why "finality" in Bitcoin isn't an instant, absolute status the way a bank's "transaction complete" message is — it is a probability curve that approaches certainty as confirmations accumulate.

Because the cost of reversing a transaction scales with its depth, merchants and exchanges calibrate how many confirmations they require to the value at stake. A small payment isn't worth an attacker's effort to reverse, so it can be treated as final almost immediately. A large payment is worth defending against more rigorously, so more confirmations are required before funds are treated as settled.

It helps to name the failure mode confirmations protect against: a chain reorganization (reorg). If two miners find valid blocks at nearly the same time, the network briefly has two competing versions of the most recent block. Normally this resolves within one block as everyone converges on whichever chain extends further — a shallow, harmless reorg. A malicious reorg, where an attacker deliberately tries to rewrite several blocks of history to reverse a payment they already received goods for, is what deep confirmation counts are specifically designed to make economically irrational.

A related wrinkle worth naming: an unconfirmed transaction (zero confirmations) sitting in the mempool is not yet final at all. It can, in rare cases, be replaced before being mined — through a mechanism called Replace-By-Fee, where the sender rebroadcasts a conflicting transaction with a higher fee that miners prefer. This is why businesses accepting instant, zero-confirmation payments for low-value goods are taking on a small, deliberate risk, not a theoretical one; it's manageable only because the cost of attempting such a replacement rarely clears the bar of being worth it for a $5 coffee.

Confirmation counting is simply arithmetic on block height: if your transaction was mined in block 800,000 and the current tip of the chain is block 800,006, you have 6 confirmations. A wallet or block explorer calculates this automatically:

confirmations = current_block_height - transaction_block_height + 1

Worked Example

A simple table illustrates how confirmation requirements typically scale with transaction value:

| Transaction | Typical confirmations required | Approx. wait | |---|---|---| | $20 coffee purchase | 0–1 | Instant to ~10 min | | $500 retail purchase | 1–2 | ~10–20 min | | $10,000 OTC trade | 3 | ~30 min | | $500,000 exchange withdrawal | 6 | ~1 hour |

The logic behind the table: at $20, the cost of mounting a reorg attack vastly exceeds any possible gain, so merchants accept the risk of an unconfirmed or single-confirmation payment for speed. At $500,000, even a small probability of a successful attack is worth guarding against, so the business waits for roughly an hour of accumulated proof-of-work security before treating the funds as irreversibly theirs. The relationship isn't linear — it's about matching defense effort to what's actually at risk, the same logic a bank uses when it holds a large check for several business days but clears a small one instantly.

Major exchanges publish their own confirmation policies for exactly this reason — a well-known exchange, for example, has historically required around 2 confirmations for Bitcoin deposits of modest size but more for very large transfers, adjusting its own risk tolerance the same way the table above does.

Exercise

A friend is closing on a real estate down payment of $50,000, to be paid in Bitcoin. The title company asks you to recommend a confirmation count before they release the deed. Using the reasoning from this lesson (not a fixed rule), write two to three sentences recommending a confirmation count and explaining why that number fits the stakes involved.

Answer key for self-check: A reasonable recommendation is 6 confirmations (roughly one hour), the same standard many exchanges use for large withdrawals — $50,000 is a substantial, irreversible real-world commitment (a deed transfer), so it's worth the extra hour to ensure the depth of buried work makes any reversal attempt computationally and economically irrational. Going lower (say, 1 confirmation) would expose the title company to a real, if small, risk of a reorg attack reversing the payment after the deed has already changed hands — a risk not worth taking for a one-time real estate transaction where an hour's delay costs nothing material.

Recap

• A confirmation is one block mined on top of your transaction's block; more confirmations mean more accumulated proof-of-work securing it against reversal, specifically against a chain reorganization attack.
• The right number of confirmations to require scales with the value at risk, not a single fixed rule for every payment — and zero-confirmation transactions carry a small, real replacement risk.
• Confirmations trade speed for certainty — for payments that need to be fast and cheap regardless of value, the next lesson covers Lightning Network as an alternative.