How does the mechanism work?
The serialized header is 80 bytes: version, previous-block hash, Merkle root, time, encoded target and nonce. The target field represents the proof-of-work threshold in compact form. The nonce is a field miners can vary while searching.
A Merkle root is a hash commitment derived from the transactions. Changing committed transaction data changes the commitment and therefore the header. The previous-block hash connects the candidate to a particular chain history.
The previous-block hash commits a candidate to a particular parent. Changing that parent produces a different header even if the candidate’s transaction list is unchanged. A node therefore evaluates the candidate in the context of that parent’s history, including the expected target and applicable rules. A header cannot be detached from its ancestry and assigned the same meaning elsewhere. This link also explains why a confirmation count grows through later blocks: each child names its parent, extending the history containing the transaction. It is the relationship between headers, rather than repeated copies of the original payment, that connects later work to earlier inclusion.
What would you see in an example?
Suppose a miner changes the block’s issuance transaction in its candidate block. That changes transaction data committed through the Merkle root. The miner must update the header commitment before testing the new candidate. A successful hash for the old header does not transfer to the changed header.
How do the header fields add up?
Count the serialized fields to see the fixed layout. Version uses 4 bytes, previous-block hash 32, Merkle root 32, time 4, compact target 4 and nonce 4. The sum is 80 bytes. The transaction count and transactions follow outside this header. A block can therefore contain many transactions while the header length remains fixed.
For a worked change sequence, imagine altering an output in an ordinary candidate transaction. Its transaction identifier changes. That changes hashes along its Merkle branch and the root committed in the header. The header’s 80-byte length stays the same, but its contents change. The miner must hash that new header; a qualifying proof for the earlier bytes is no longer a proof for this candidate.
The nonce is a 4-byte field, which gives 2^32 possible bit patterns. Searching those patterns does not exhaust every possible candidate header. A miner can change other permitted candidate data, including the issuance transaction transaction, and recalculate the Merkle root. The search is over concrete headers, not a small puzzle with a unique answer that improves gradually.
The time and compact-target fields are not just descriptive labels. Nodes apply rules to the candidate time and expected target. Compact target encoding represents a much larger threshold in a short field. When you inspect a header, distinguish the encoded target, the decoded threshold and the resulting header hash. They interact during validation but none is the same object as transaction fees or the subsidy.
Common misunderstandings
An 80-byte header does not contain enough information to verify all transaction spending conditions. Headers let a reader follow commitments and accumulated work; full transaction validation needs block data and the relevant prior outputs.
The Merkle root is not a compressed list you can decompress into every transaction. It is a commitment computed from that list. A proof can connect a supplied transaction identifier to a root, but the root alone does not reveal omitted transactions or certify that each one spends valid inputs.
Check yourself
If a candidate adds a transaction, must its header grow beyond 80 bytes?
Reveal the answer
No. The Merkle root changes, while the fixed field layout remains 80 bytes. The block data outside the header grows.
What does this diagram leave out?
A header is not enough to check every transaction rule. A node that validates a block needs the relevant block data and prior chain state. A header meeting its target does not prove that the referenced transactions are valid. The time field is also not a guaranteed real-world timestamp for each payment.
Which primary sources explain the rules?
Sources: Block header reference; Block chain developer guide.
Sources: Header field widths and encoding.