Finality describes the permanence of settlement: how confidently a completed transfer can be expected to remain in place. Bitcoin provides probabilistic assurance that grows with further valid work. No universal confirmation count alone rules out a change of chain branch or determines whether an entire agreement has been legally fulfilled.
At first, Paul sees that his wallet has learned about the transaction. That is not the same as inclusion in a block. Once the block exists and further blocks build on it, replacing that history requires overcoming more work. This is how practical Finality increases. The resources of a potential attacker and the condition of the network still matter. The protocol does not issue a mathematical certificate of irreversibility; the recipient assesses the strength of the evidence for accepting a particular payment. [1] [2]
A Full Node independently checks Bitcoin’s rules. It does not accept a history merely because it is long. It first validates it, then selects the valid branch with the greatest cumulative work. This is work demonstrated by blocks, not a vote counted by people or their coin holdings. More work cannot make an invalid transaction valid. For Paul, both questions matter: does the payment comply with the rules, and how deeply is it buried in the valid history currently being followed? [1]
In our example, Paul’s transaction is in the block at height 800000, and the current tip of the same branch is at height 800005. Height is a block’s position, not a time. The calculation is 800005 − 800000 + 1 = 6 confirmations, including the transaction’s own block. We are not counting only the blocks added afterwards. A payment found only in the mempool, the node’s collection of unconfirmed transactions, has 0 confirmations. Waiting by itself does not increase the count. [2] [3]
The network can briefly know competing blocks and later continue along a different valid branch with more work. This change of active history is called a reorganisation. In Bitcoin Core 28.0 documentation, the block-header query getblockheader reports confirmations = -1 when that block is outside the active chain. This describes the block and does not mean all its payments are lost. Paul’s transaction may also appear in the new branch, remain unconfirmed or conflict with another transaction. Its individual status must be checked again. [1] [3]
The developer guide mentions 6 confirmations as a commonly used threshold for valuable payments, while also explaining the need for risk assessment. It is a recipient’s acceptance rule, not a point at which Bitcoin’s consensus changes. Paul should consider the bike’s value, the potential loss and the reliability of his verification; a number cannot decide for him. An average of roughly an hour does not mean six blocks always arrive within an hour. Mining has no fixed timetable, and an older general recommendation is not a guarantee for every situation. [2]
Paul may have confirmed BTC and still face a dispute over handing over the bike or its condition. PFMI, the international principles for financial market infrastructures, require a clearly defined point of final settlement and a boundary beyond which a participant cannot revoke an instruction. That is a different framework from counting Bitcoin blocks. Confirmations alone do not determine a contract’s legal effect, a bank payment’s finality or ownership of the item sold. Checking the payment matters, but does not replace the other terms of the trade. [4]
If Paul and the buyer agree on a refund, it normally takes the form of a new transaction by the recipient of the original payment. The original transfer stays in the history. Bitcoin has no central support desk with a button to cancel a confirmed payment on request. A reorganisation changes the network’s active history; it is not a customer service for correcting mistakes. Check the recipient and amount before sending. Waiting for more confirmations will not fix a payment sent incorrectly. [5]
For a payment-app operator, work does not end when a payment is accepted. The app should record the transaction, its block and the verification source, and detect whether its node has fallen behind the network. The confirmations value is a status at the time of a query, not a permanent certificate. If the count falls or a conflict appears, the app needs predefined handling rules and a fresh check of the active branch. An old screenshot is not new evidence. For Paul, the practical lesson is to decide from the current state of his payment, not merely from what his wallet once showed. [2] [3]
For the clearest picture, read this entry together with Confirmation, Proof of Work, Settlement risk, Delivery versus payment. The reverse links also lead from Byzantine Generals Problem, Delivery versus payment.