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.

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.

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?