A customer sends bitcoin, the receiving wallet displays the payment, and an order is ready to ship. The remaining decision belongs to the recipient: when is the payment sufficiently settled to release something that may be difficult to recover?
Bitcoin confirmations help answer that question. Reading them correctly requires separating three events: seeing a transaction, finding it in the active blockchain, and deciding that it meets an acceptance policy. The familiar six-confirmation rule addresses the third event, but it does not create an absolute guarantee.
Count blocks rather than minutes
A transaction has one confirmation when it appears in a block on the active chain. Each subsequent block extending that chain adds another. Six confirmations therefore means the containing block plus five blocks after it. An unconfirmed payment has not reached that first step. The Bitcoin developer guide describes confirmations as increasing protection against a conflicting spend, while warning that merely broadcasting a payment does not ensure the recipient gets paid. Bitcoin developer guide: verifying payment.
The counter measures chain depth. A timer cannot substitute for it. Bitcoin's difficulty mechanism targets roughly ten minutes between blocks on average; individual arrivals vary. Waiting an hour does not establish that six confirmations occurred, and the wait before initial inclusion can add further delay. A fulfillment system should check the payment's actual status when it is ready to act. Bitcoin developer guide: proof of work.
What a reorganization changes
Two miners can find different valid blocks at approximately the same time. Different nodes may initially follow different tips. As one branch accumulates more proof of work, nodes following the other branch switch to the stronger valid chain. That replacement of previously accepted blocks is a chain reorganization, commonly shortened to reorg. The selection concerns accumulated work, rather than a vote of websites or wallets. Bitcoin developer guide: block height and forking.
For a recipient, the important question is what happened to the particular payment. Removal of its old block does not by itself establish that the payment was permanently lost. Bitcoin Core's wallet documentation explicitly accounts for transactions removed by a reorg and subsequently included again in the active chain. Their current confirmation counts can be positive. Check the current result before deciding whether a customer needs to take action. Bitcoin Core: listsinceblock.
Why six became a convention
The developer guide calls the choice of six somewhat arbitrary. That makes it a documented risk-management convention rather than a special boundary at which Bitcoin changes its consensus rules. Bitcoin developer guide: verifying payment.
The underlying reasoning appears in the whitepaper. Changing a past payment requires an attacker to build an alternative history and catch up with the work supporting the accepted chain. Under its model, an attacker with less hashing power than the honest network becomes less likely to catch up as the deficit grows. The calculations depend on assumptions about the attacker's resources and progress. They do not turn a displayed confirmation count into a universal, real-world probability of loss. Bitcoin whitepaper, sections 4 and 11.
For merchants, the practical inference is to connect a waiting policy to the loss they could actually suffer. Releasing an expensive, immediately transferable item deserves different scrutiny from reserving inventory that remains under the seller's control. Those business choices should be made before a customer is waiting at checkout.
Build an acceptance checklist
A workable policy can ask four questions:
- Does the payment match the expected receiving destination and amount?
- Has the receiving system finished synchronizing and is it processing new blocks?
- Does the transaction currently meet the confirmation threshold chosen for this payment?
- Is there a conflict or other exception requiring someone to review fulfillment?
These are operational recommendations drawn from the mechanics above, not a prescribed number of blocks for every sale. Communicate the acceptance condition to customers in advance. If goods cannot be recovered once delivered, define who can approve an exception and record that decision.
For systems built on Bitcoin Core, the documentation supplies useful building blocks. The gettransaction response reports confirmations and detected wallet conflicts; a negative confirmation value means the transaction conflicted that many blocks ago. Software must handle that state rather than treating every numeric value as progress toward completion. Bitcoin Core: gettransaction.
Node health also needs its own check. Core's getblockchaininfo exposes the validated block height, validated header count and estimated verification progress. These fields help operators investigate whether their payment view is current; no single progress indicator should become a blanket assurance that a payment is safe. Bitcoin Core: getblockchaininfo.
Finally, keep payment observation separate from fulfillment authorization in the order record. A customer can receive a prompt acknowledgment while the order remains pending. That simple distinction makes the waiting period understandable and gives staff a clear response if transaction status changes before shipment.