Module 5: How Bitcoin Blocks and Confirmations Work
5.1 Introduction
In traditional payment systems, when you send money, the payment often appears instantly and is considered final.
In Bitcoin, payment finality is probabilistic , meaning a transaction becomes more final as more blocks are mined on top of it — but is never 100% final immediately.
This is a critical concept for both wallet design and user education.
Understanding confirmations and block reorganizations (reorgs) is essential for:
Designing secure user experiences (especially for merchants, exchanges, remittances).
Explaining why Bitcoin transactions are not “instant" even when broadcast.
Protecting users from rare but catastrophic edge cases.
5.2 What is a Confirmation?
When a user sends Bitcoin:
Their transaction first enters the mempool (the pool of unconfirmed transactions waiting to be mined).
Miners pick transactions from the mempool to include in the next block, prioritizing higher-fee transactions.
Once a transaction is included in a mined block, it has 1 confirmation.
Each subsequent block built on top of that block adds another confirmation.
Confirmations represent how deeply buried a transaction is inside the blockchain history.
The deeper the transaction is buried, the harder it becomes to reverse or reorganize.
5.3 Confirmation Timeline Example
Scenario:
Ngozi in Abuja sends 0.3 BTC to Wanjiku in Nairobi.
Ngozi’s transaction is broadcast to the network.
The transaction appears in the mempool.
After 9 minutes, a miner includes the transaction in a block.
Now:
1 block mined → Transaction has 1 confirmation.
2 blocks mined → Transaction has 2 confirmations.
6 blocks mined → Transaction has 6 confirmations (high security).
5.4 Why Multiple Confirmations Are Recommended
Because of the way Bitcoin’s consensus works:
Blocks are built independently by miners.
It is possible (though rare) that two miners find a valid block at almost the same time.
This creates a temporary chain split.
Nodes follow the longest chain rule — the chain with the most accumulated proof-of-work wins.
If a competing chain grows faster, transactions in the "losing" chain may get replaced or reorganized — meaning transactions once considered "confirmed" might disappear.
5.5 Block Reorganization (Reorg) Explained
A block reorg happens when:
Two different versions of the blockchain exist temporarily.
Nodes switch to a longer chain that excludes certain previously confirmed blocks.
Transactions in orphaned blocks go back to the mempool — they become unconfirmed again.
Diagram:
5.6 How Common Are Reorgs?
1-block reorgs happen occasionally (maybe once every few days on Bitcoin).
2-block reorgs are rare.
3+ block reorgs are extremely rare on Bitcoin mainnet.
Bitcoin’s mining power distribution, economic incentives, and node behavior make deep reorgs extremely unlikely without massive coordinated attacks.
5.7 Industry Standards for Confirmations
| Use Case | Typical Confirmation Requirement |
|---|---|
| Small Retail Payments | 0–1 confirmation (Accept risk of reorg for speed ) |
| Exchanges Deposits | 3–6 confirmations (Standard security balance ) |
| Large Enterprise Settlements | 6+ confirmations (Maximum caution against reversal) |
5.8 PM Reflection Points: Building Wallet UX
If you are designing a Bitcoin wallet:
Explain confirmations to users.
Always show transaction status:
Unconfirmed (0 confirmations)
Confirming (1–5 confirmations)
Finalized (6+ confirmations)
Do not instantly mark funds as fully available after 0 confirmations unless you are willing to accept the risk of reorgs.
Allow flexibility:
Developers should set different confirmation thresholds for different flows:
Fast micropayments may accept 0–1 confirmation.
Custody services may require 6 confirmations or more.
Handle reorg gracefully:
If a transaction gets dropped from a block, wallets should:
Update transaction status to unconfirmed.
Notify users without causing panic.
Re-broadcast if necessary.
5.9 Practical Real-World Example
Ada is running a Bitcoin payment app in Lagos.
She receives a 0.01 BTC payment from a customer at her café.
Because it’s a small amount:
Ada accepts the transaction after 0 confirmations, relying on network honesty.
If she were running a Bitcoin exchange, she would instead wait for 3–6 confirmations before crediting a customer deposit.
5.10 Summary of Module 5
Bitcoin confirmation is a process, not an instant event.
1 confirmation = included in one block (good, but still reversible under rare conditions).
6 confirmations = considered extremely secure (virtually irreversible under Bitcoin’s current security model).
Block reorganizations are real but rare.
Wallets must:
Track confirmation depth properly.
Handle reorgs intelligently.
Set clear user expectations around confirmation times and payment finality.
Module 5 Complete
We now fully understand how Bitcoin transactions move from broadcast to confirmed to finalized,
and why confirmations, mempool status, and reorg risk are core wallet UX realities, not just engineering backend details.
