What changes when a transaction gains confirmations?

How does the mechanism work?

A confirmation count describes a transaction’s position in the chain a node currently accepts. The work in that history matters when considering competing chains, but a count is not a certificate from a central operator.

Nodes can temporarily disagree about the latest block. When the valid chain with the most accumulated work changes, a reorganisation can replace blocks. A transaction in a replaced block may later be included again, remain unconfirmed or conflict with the accepted history.

Always attach the count to an observer’s chain view. Two interfaces can temporarily show different tips or update at different moments without changing the arithmetic. A custodial account can add another delay before displaying a credit. Ask which block contains the transaction and which tip is being used before comparing counts. If inclusion itself changes during a reorganisation, recalculate from the accepted history rather than adding elapsed time to an old count. This approach also keeps confirmations separate from authorisation: a later block does not repair a bad signature, change the recipient or ask the sender to approve the transaction again.

How do you calculate a count from two heights?

For a transaction included at height H in the chain you accept, and a current tip at height T, the confirmation count is T - H + 1. The plus one counts the containing block itself. An unconfirmed transaction does not have a containing height in that accepted chain, so the same subtraction is not applied to a pending payment.

Use an invented example: the containing block has height 900,000 and the tip has height 900,002. The count is 900,002 - 900,000 + 1 = 3 confirmations. Only the first of those blocks contains the transaction. The later blocks commit to prior history through their previous-block hashes. They do not need to repeat its bytes or collect a fresh signature from its sender.

Now imagine a competing valid branch replaces the block that contained it. Your old subtraction no longer describes inclusion in the accepted chain. If the transaction is included again at a different height, calculate the count from its new containing block. If it is absent, it may become unconfirmed; if a conflicting spend is accepted, its inputs may no longer be available.

A reorganisation requires comparison of valid histories and their accumulated work, not a vote by a fixed number of peers. A node checks the replacement history under its rules. The confirmation count is a useful summary of position, but it omits difficulty, competing work, transaction dependencies and network conditions. Those omissions explain why a count alone cannot guarantee finality for every situation.