The Block Header (80 bytes)

The block header is the single most important 80 bytes in Bitcoin. It is what miners hash trillions of times per second; it is what chains one block to the next; it is what a light client downloads instead of the whole blockchain. Everything Bitcoin calls “the block’s hash” is really the double-SHA-256 of just these 80 bytes — never the transactions themselves. If you understand the six fields packed into this header, you understand the skeleton of the entire chain.

The exact layout

The header is six fields, in this fixed order, totalling exactly 80 bytes:

 Offset  Size   Field              What it is
 ──────  ────   ───────────────    ───────────────────────────────────────────
   0      4 B   version            consensus/upgrade signaling bits
   4     32 B   prev block hash    double-SHA-256 of the PREVIOUS header (the link)
  36     32 B   merkle root        one hash committing to every tx in this block
  68      4 B   timestamp          Unix time (seconds) the miner claims
  72      4 B   bits               the target, in compact form (difficulty)
  76      4 B   nonce              the number miners grind to find a valid hash
 ──────  ────
        80 B   TOTAL

The block’s identifier — its “hash” — is computed as:

block hash = SHA256( SHA256( these 80 bytes ) )

That’s the famous double-SHA-256. Note what’s not in here: no transactions, no amounts, no signatures. Just six fields, two of which (the prev hash and the Merkle root) are themselves commitments to large amounts of data elsewhere. The header is a summary that can stand in for the whole block.

Why exactly these six — field by field

1. Version (4 bytes)

Signals which consensus rules the block follows and is used to coordinate soft-fork upgrades (miners flip bits to vote readiness). It answers: which rulebook does this block claim to obey?

2. Previous block hash (32 bytes)

The hash of the previous header. This single field is what turns a pile of blocks into a chain — each header points backward to its parent, so editing any old block breaks every block after it. This is the heart of immutability, covered in Chaining Blocks.

3. Merkle root (32 bytes)

One hash that commits to every transaction in this block via a Merkle tree. Change any transaction and this root changes, so the header is welded to its transaction list. It answers: what ledger update does this block carry, and how do I know it wasn’t tampered with?

4. Timestamp (4 bytes)

The Unix time (seconds since 1970) the miner claims the block was created. It isn’t trusted blindly — nodes enforce loose rules on it (covered in Block Validation) — but it feeds the difficulty adjustment that keeps blocks near the ~10-minute target.

5. Bits / target (4 bytes)

A compact encoding of the target: a 256-bit threshold the block hash must come in under. The 4 bytes are a floating-point-like packing — a 1-byte exponent and a 3-byte mantissa — that expands into the full 256-bit number. Smaller target = harder. This is the dial the network turns every 2016 blocks to keep block timing steady; the full story lives in Proof of Work.

6. Nonce (4 bytes)

The one field miners are free to change at will. Mining is the search for a nonce (plus other tweaks) that makes the header’s double-SHA-256 fall below the target. Because hash functions are unpredictable, the only way to find such a nonce is to try enormous numbers of them — which is exactly the “work” in Proof of Work.

Why the header is the thing that gets mined

                          vary the nonce
                                │
                                ▼
   ┌──────────────────────────────────────────┐
   │   80-byte header (with current nonce)     │ ──► SHA256d ──► is it < target?
   └──────────────────────────────────────────┘                    │
        ▲   ▲           ▲                                  no ◄──────┤
        │   │           │                                           yes
     version│        merkle root                                     │
         prev hash    (locks in all txs)                             ▼
                                                            VALID BLOCK FOUND

The header is engineered to be hashable in bulk. It’s tiny (80 bytes), fixed-size, and contains a single freely-variable field (the nonce). Miners aren’t hashing the megabyte of transactions over and over — they hash the same 80 bytes with a new nonce each time, billions of times a second. The expensive transactions are committed once via the 32-byte Merkle root, then ignored during the grind.

Only ~4 billion nonces — then what?

A 4-byte nonce gives only ~4.3 billion possibilities, which a modern miner exhausts in a fraction of a second. When that runs out, miners change other parts of the header’s input — the timestamp, or the coinbase transaction’s extra-nonce field, which alters the Merkle root. Either way the search space is effectively unlimited; the 4-byte nonce is just the innermost, fastest loop.

The header is a claim, not a proof — until validated

A well-formed 80-byte header proves nothing on its own. A node still independently recomputes the Merkle root from the actual transactions and re-checks that the hash beats the target. The header is what gets hashed; validation is what makes it trusted.

By the numbers — why headers fit on a phone but the chain doesn’t

A light client follows the chain by downloading only the 80-byte headers — one per block — instead of every full block. The gap in scale is the whole reason SPV is possible:

   header chain:  80 bytes × ~950,000 blocks  ≈  76 MB     (every header in history, mid-2026)
   full chain:    full block data             >  500 GB    (archival node, mid-2020s)

   new headers:   80 bytes × ~144 blocks/day  ≈  12 KB per day

So verifying proof of work across all of history costs an SPV wallet well under 100 MB of headers, versus the hundreds of gigabytes a full node stores — and it grows by only about 12 KB a day, a rounding error on any modern device. That asymmetry is exactly what the 80-byte header buys.

The thread

How does this help untrusting strangers agree on one ledger? The 80-byte header is a compact, universally-checkable summary of a block. Its prev-hash field locks the block into one shared history; its Merkle root locks in the exact transactions; its bits field defines a difficulty everyone agrees on; and its nonce is proof that real energy was spent. Any stranger can download these 80 bytes, recompute one hash, and verify the block met the rules — no trust, no authority, just arithmetic on a shared format. The header is the handshake protocol of Nakamoto consensus.

The architect’s lens

Step back from the six fields and answer the five questions that turn an implementer into an architect:

• Why does it exist? To compress an entire block into a fixed 80 bytes that can be hashed in bulk and chained — a summary that stands in for the megabyte of transactions it commits to.
• What problem does it solve? It makes mining cheap to attempt and trivial to verify: miners grind the same 80 bytes with a new nonce billions of times a second, while any stranger recomputes one double-SHA-256 to check the result against the target.
• What are the trade-offs? Everything heavy is moved out of the header into commitments — the 32-byte prev-hash and 32-byte Merkle root — so the header alone proves nothing until a node independently rebuilds those structures and re-checks them.
• When is a different design better? If you didn’t need cheap, repeatable hashing for proof of work — say a permissioned chain with signed blocks — you’d carry richer metadata in the block and skip the nonce/bits machinery entirely.
• What breaks if I remove it? Drop the fixed 80-byte summary and there’s nothing compact to mine, nothing for the prev-hash to point at, and no header chain for SPV clients to download — light verification on a phone becomes impossible and you’re back to shipping full blocks to hash.

Check your understanding

1. List the six header fields in order with their byte sizes. What do they add up to?
2. How is a block’s hash computed, and what data is conspicuously absent from the header?
3. Which single field turns a heap of blocks into a chain, and why?
4. Why is it efficient that miners hash the header rather than the full block?
5. A 4-byte nonce only allows ~4.3 billion attempts. How do miners keep searching once those are exhausted?

Show answers

1. Version (4 B), previous block hash (32 B), Merkle root (32 B), timestamp (4 B), bits/target (4 B), nonce (4 B) — in that fixed order, totalling exactly 80 bytes.
2. The block hash is SHA256(SHA256(...)) — double-SHA-256 — of just the 80-byte header. Conspicuously absent: the transactions themselves, the amounts, and the signatures. The header is a summary that stands in for the whole block.
3. The previous block hash. Each header carries the hash of its parent’s header, so the blocks form a backward-pointing chain and editing any old block breaks every block after it — the heart of immutability (Chaining Blocks).
4. The header is tiny (80 bytes), fixed-size, and has a single freely-variable field (the nonce). The megabyte of transactions is committed once via the 32-byte Merkle root, so miners re-hash the same 80 bytes billions of times a second instead of the whole block.
5. They change other header inputs: the timestamp, or the coinbase’s extra-nonce field, which alters the Merkle root. Either way the search space is effectively unlimited — the 4-byte nonce is just the innermost, fastest loop (see the mining process).