What does a validating node check for itself?

How does the mechanism work?

Start by separating roles. Mining searches for a candidate header satisfying a target. Validation checks whether the entire candidate meets the rules. Relaying shares information with peers under local policy. One participant can perform several roles, but the jobs remain different. Receiving a block from many peers does not relieve a node of the need to check it.

Header checks include proof of work and the expected target in the chain context. Block checks include transaction commitments, permitted weight and structural requirements. Transaction checks resolve inputs, enforce spending conditions and prevent invalid value creation. Some checks need earlier state, so a collection of standalone transaction bytes is not enough to validate arbitrary chain history.

The UTXO set records outputs still available to spend in the accepted chain. Applying a block consumes referenced outputs and creates new ones. A later transaction in the same block can spend an earlier transaction’s output when all relevant rules pass. A spend cannot validly consume an already spent output simply because two peers advertised it.

State changes must be reversible when a node switches to a competing valid history. The node needs to undo outputs created by disconnected blocks and restore outputs they consumed before applying the replacement branch. This does not mean arbitrary balances are edited by an administrator. It means the node derives its current spendable set from the history it accepts. The distinction is useful when a payment loses inclusion during a reorganisation: its status follows the newly accepted history. Independent validation is therefore a continuing process over chain context, rather than a one-time approval that is attached permanently to transaction bytes.

How do the protocol numbers work in an example?

Use an invented candidate at height 840,000. Its scheduled subsidy is 312,500,000 satoshis, or 3.125 BTC. Suppose its transactions pay 20,000 satoshis in fees. A issuance transaction output sum of 312,520,001 satoshis exceeds the permitted subsidy-plus-fee sum by 1 satoshi. The node rejects it even if its header meets the required target.

Next imagine the claimed reward is within bounds, but two transactions spend the same prior output. The node cannot apply both spends to one accepted state. A qualifying hash, a familiar sender address or a long peer list cannot repair the conflict. Each transaction must be valid in the context in which the block applies it.

issuance transaction outputs also have a maturity rule: they need 100 blocks of age before being spent. If a issuance transaction is created at height 900,000, height 900,100 is the earliest candidate height meeting that maturity comparison. This is a consensus constraint on that output, separate from an ordinary interface’s preferred confirmation count.