Bitcoin settlement and confirmations

EN source master · P02-L01 · 30 minutes estimated · needs_review

Read-only study. No wallet connection, real money, seed phrase, private key, signature or live trade. Duration is an editorial estimate; visual assets are specifications, not deployed components.

A confirmation count is meaningful only relative to a chain view. A transaction can be known to a node without being included in its selected chain.

What confirmation counts describe

Bitcoin nodes validate blocks and select among valid histories by accumulated work. Forks can temporarily produce competing blocks; a height alone is therefore not a unique block identifier [BTC]. A confirmation count is not a certificate about the recipient or economic purpose.

For an ordinary included transaction in the selected chain, this lesson uses tip height minus inclusion height plus one. The inclusion block counts as the first confirmation. This formula assumes both heights refer to the same selected chain and the transaction remains in that chain.

Keep the mempool separate

A pending transaction is not assigned an inclusion height in this exercise. Do not insert a guessed height and calculate a positive count. A node's view is also scoped: one node not showing a transaction does not prove every node lacks it.

Reorganizations change the question

If the selected block at a height changes, first determine whether the transaction remains included and where. Reusing the old count with the new tip can produce a false claim. Preserve block hashes and the observation context so the comparison is reproducible.

Increasing depth generally changes the work needed to replace a history, but it is not a universal promise of irreversibility. Do not teach a single number as guaranteeing all payments, every network condition or merchant acceptance. Confirmation policy and protocol mechanism are distinct.

Report confidence without hiding conditions

Say ‘the supplied selected chain contains T in block H, with N confirmations at tip K’. Then state what the record omits. A count is an arithmetic result under a chain-view assumption; the example is fictional and supplies no independent validation of work or consensus.

Evidence-state classification

OBSERVED in the illustrative packet: selected tip/inclusion fields at T0 and the changed block at T1. INFERRED: 105−104+1=2 confirmations at T0 under selected-chain ancestry. UNKNOWN: A's later inclusion from the partial T1 packet. INSUFFICIENT EVIDENCE: the old height plus a higher tip establishes three current confirmations or guarantees irreversible safety.

• Confirmation: inclusion depth in a selected chain.
• Tip: current end of a node's selected chain.
• Reorganization: change in selected chain history.
• Mempool: node's pending-transaction view.

ILLUSTRATIVE. At T0 SIM-BTC tip=105; SIM-TX-A included at104 in BLOCK-X; SIM-TX-B pending. At T1 selected tip=106; height104 now has BLOCK-Y and A is absent from the supplied selected-chain records. No later location for A is supplied.

Transaction timeline with T0 BLOCK-X104→tip105 and alternative T1 BLOCK-Y104→tip106. Mark A location unknown on T1; B pending. Alt: A has two confirmations only in the original fictional chain view.

Confirmation arithmetic and the inconsistency of reusing a stale inclusion context.

Real Bitcoin settlement, universal irreversibility or human attribution.

• Off-by-one confirmation counting.
• Counting pending transactions as included.
• Using height without block identity after a fork.

Calculate A's T0 confirmations. State B's inclusion status. Explain why A cannot be assigned three confirmations at T1 from the old height alone.

Submit a short evidence table and reasoning, using only the provided material. Suggested allocation: study 12 min, inspection/calculation 8 min, correction/quiz 10 min.

• Selected-chain assumption.
• Block hash plus height.
• Tip context.
• Recheck inclusion after changes.

A confirmation count is meaningful only relative to a chain view. A transaction can be known to a node without being included in its selected chain. The supplied material supports confirmation arithmetic and the inconsistency of reusing a stale inclusion context. It does not establish real Bitcoin settlement, universal irreversibility or human attribution.

• Compute confirmation count under a stated tip.
• Separate mempool presence from inclusion.
• Describe reorganization uncertainty without a universal guarantee.

P02-L02 after reviewing this exercise and its prerequisites.

NONE. The authoritative catalog requires no product access for this lesson. Use the frozen/offline material.

• [BTC] Bitcoin developer guide — Block chain — Valid blocks, UTXOs, work and forks; not historical fixture authentication. Checked 2026-10-01.

Synthetic values are author-created exercise inputs. Historical values, if any, must use the linked dataset and its narrower provenance. Source inspection is not independent editorial acceptance.