The header is the block's proof-of-work identity
Every block header contains six fields: version, previous-block hash, Merkle root, timestamp, encoded target and nonce. Together they occupy 80 bytes. Miners repeatedly hash candidate headers while changing the nonce and other template data until the resulting number is below the current target.
The previous-block hash links the candidate to a specific parent. A header with valid proof of work is not enough on its own: a full node also validates the block body and every transaction before accepting it.
The body starts with a transaction count
After the header, the serialized block contains a CompactSize transaction count followed by the transactions in order. The first transaction is always the coinbase transaction. It has a special input and lets the miner claim no more than the permitted subsidy plus the fees from included transactions.
Since BIP34, the coinbase input begins with the block height. The coinbase can also carry pool data and, for SegWit blocks, a witness commitment. Ordinary transactions then spend existing outputs and create new ones.
The Merkle root commits to transaction order
Transaction identifiers are paired and hashed repeatedly until one 32-byte Merkle root remains. If a level has an odd number of hashes, its final hash is paired with itself for that round. Changing a transaction or its position changes the resulting root and therefore changes the block header.
A Merkle branch lets a verifier prove that one transaction is included without supplying every transaction in the block. The proof contains the neighbouring hashes needed to reconstruct the path to the root.
Witness data has a separate commitment
The header's Merkle root is built from traditional transaction identifiers, which do not include SegWit witness data. BIP141 therefore defines a witness Merkle root and places a commitment to it in an output of the coinbase transaction.
This keeps the header format unchanged while ensuring upgraded nodes can verify that witness data has not been altered. Older nodes can still process the compatible base block view, but they do not enforce the SegWit witness rules themselves.
Validation works from the outside in
A node checks header linkage, proof of work and contextual rules, then verifies the block's size or weight, Merkle commitments, coinbase value and every transaction. It also checks that inputs are unspent and that scripts and witness programs succeed.
A block explorer is useful for inspection, but it is not the authority that makes a block valid. Your node reaches that conclusion by reproducing the checks against its own validated state.
Visual recap
From block header to validated state
The header commits to history and transaction data; the body must still pass complete node validation.
Read 80-byte header
Check parent and target
Parse transaction count
Verify coinbase
Rebuild commitments
Validate every spend
Key vocabulary
Terms worth knowing
- Block header
- The 80-byte structure containing version, parent hash, Merkle root, time, encoded target and nonce.
- Coinbase transaction
- The first transaction in a block, used to claim permitted subsidy and fees and carry required commitments.
- Merkle branch
- The neighbouring hashes needed to prove one item belongs to a committed Merkle root.
Worked example
One transaction changes after template construction
A miner changes one output in a candidate block's transaction list after calculating the original Merkle root.
- 1The transaction identifier changes
- 2Hashes on its Merkle path change
- 3The Merkle root changes
- 4The block header changes
- 5Previous proof-of-work attempts no longer apply to the new header
The Merkle root binds the header to the exact ordered transaction set, so changing committed data creates a new proof-of-work candidate.
Common misconceptions
What learners often get wrong
Misconception
A valid header hash proves every transaction is valid.
More accurate
It proves work on that header. Full nodes separately validate the block body, commitments and transactions.
Misconception
An empty block contains no transactions.
More accurate
It still contains a coinbase transaction; it has no additional ordinary transactions.
Try it yourself
Trace a four-transaction Merkle tree on paper.
- Label four fictional txids
- Pair and hash each neighbouring pair
- Hash the two parent values
- Change one fictional txid
- Mark every value that must change
Use fictional values and public information only. Never enter seed words, private keys or other wallet secrets into a learning exercise.
Key takeaways
- A block contains an 80-byte header followed by a transaction count and ordered transactions.
- The first transaction is the coinbase and may claim subsidy plus fees within consensus limits.
- The Merkle root commits to transaction identifiers and their order.
- SegWit witness data is committed through the coinbase transaction.
- Valid proof of work does not excuse an invalid block body.
Lesson recap
Check what you learned
Reveal each model answer, then honestly mark whether you understood it or need another review.
1 of 3
Recall
If a miner finds a header hash below the target, must every full node accept the block?
References
