Why the Bitcoin Block Header Is 80 Bytes, Not 128 Bytes

Why the Bitcoin Block Header Is 80 Bytes, Not 128 Bytes

Bitcoin miners do not hash “the whole block” while searching for proof-of-work. They hash the serialized block header: a compact 80-byte consensus object containing the block’s version, parent reference, transaction commitment, timestamp, difficulty target encoding, and nonce. The Bitcoin Developer Reference is explicit: block headers are serialized in an 80-byte format, and that serialized format is part of Bitcoin’s proof-of-work consensus rules. (developer.bitcoin.org)

The 80-Byte Header

That totals:

4 + 32 + 32 + 4 + 4 + 4 = 80 bytes

The previous-block hash and Merkle root are 32-byte double-SHA-256 hashes, while nBits encodes the target threshold the block hash must be less than or equal to. The 4-byte nonce is an arbitrary value miners change to modify the header hash; after all 32-bit nonce values are exhausted, miners can update the timestamp or change the coinbase transaction, which changes the Merkle root. (developer.bitcoin.org)

What Is Actually Hashed?

The block hash is conceptually:

block_hash = SHA256(SHA256(serialized_80_byte_header))

The first SHA-256 receives the 80-byte header. The second SHA-256 receives the 32-byte digest produced by the first SHA-256.

That distinction matters. The header is 80 bytes, but SHA-256 internally works in 64-byte / 512-bit compression blocks. A message does not need to be exactly one or two SHA-256 compression blocks long; SHA-256 pads it according to its own rules. NIST’s SHA standard defines SHA-256 padding as: append a 1 bit, then enough zero bits to make room for a final 64-bit length field, so the padded message is a multiple of 512 bits. (NIST Publications)

The Padding Trap

An 80-byte Bitcoin block header is 640 bits.

SHA-256 compression blocks are 64 bytes each, so the first SHA-256 pass sees the header like this:

Raw header:
80 bytes

SHA-256 block size:
64 bytes

First compression chunk:
64 bytes of header data

Second compression chunk:
16 remaining header bytes
+ SHA-256 padding

The second chunk is not “empty space” Bitcoin can reuse. It is SHA-256 padding territory.

For an 80-byte message, the second 64-byte SHA-256 chunk looks like this:

[ 16 bytes header remainder ]
[ 0x80 ]
[ 39 bytes of 0x00 ]
[ 8-byte length field: 0000000000000280 ]

0x280 is 640 in hexadecimal, meaning the original message length was 640 bits.

So yes, the second SHA-256 compression block contains only 16 bytes of actual Bitcoin header data. But the remaining 48 bytes are not free header space. They are the mandatory SHA-256 padding byte, zero padding, and length field.

Why Not Make the Header 128 Bytes?

Because a 128-byte header would not neatly occupy “two SHA-256 blocks.”

That is the subtle mistake.

If the raw message is exactly 128 bytes, SHA-256 still must append padding and the length field. Since there is no room left in the second 64-byte block, padding spills into a third SHA-256 compression block. The Bitcoin Stack Exchange answer on this question points out the key boundary: a message can be up to 119 bytes and still pad to two SHA-256 blocks; at 128 bytes, padding pushes it to a third block. (Bitcoin Stack Exchange)

So the clean technical boundary is:

0–55 raw bytes     -> 1 SHA-256 compression block after padding
56–119 raw bytes   -> 2 SHA-256 compression blocks after padding
120–183 raw bytes  -> 3 SHA-256 compression blocks after padding

Bitcoin’s 80-byte header already fits in the two-compression-block class. Making it 128 bytes would make hashing more expensive, not cleaner.

The Midstate: Why Miners Care About the 64-Byte Boundary

The 80-byte header crosses the SHA-256 64-byte boundary in a useful way.

The first 64 bytes contain:

version                    4 bytes
previous block hash        32 bytes
first 28 bytes Merkle root 28 bytes
-------------------------------
total                      64 bytes

The second SHA-256 chunk begins with:

last 4 bytes Merkle root   4 bytes
time                       4 bytes
nBits                      4 bytes
nonce                      4 bytes
-------------------------------
actual header remainder    16 bytes

The nonce lives in the second SHA-256 chunk. That means miners can reuse the SHA-256 midstate after the first 64 bytes while cycling through nonce values in the second chunk. When the 32-bit nonce space is exhausted, the miner changes time or modifies the coinbase transaction, causing the Merkle root to change and a new header template to be built. The Developer Reference describes exactly this fallback: after all nonce values are tested, the time can be updated or the coinbase transaction can be changed and the Merkle root updated. (developer.bitcoin.org)

This is why the 80-byte layout is “awkward but good enough.” It gives miners a small, cacheable first chunk and a mutable second chunk.

Why Not Put a Huge Extra Nonce in the Header?

You could design a new chain that way. Bitcoin did not.

A larger header nonce would increase every block header forever. That matters because headers are not just miner input; they are the skeleton of the chain. Satoshi’s whitepaper explicitly discusses the compactness of headers: an 80-byte header every 10 minutes is about 4.2 MB per year, and simplified payment verification depends on users being able to keep only the chain of headers plus Merkle branches.

Changing Bitcoin’s header format now would also be a consensus change. Every full node, SPV client, mining device, pool protocol implementation, block parser, and header-sync system assumes the 80-byte serialized header. The Developer Reference states that the serialized header format is part of consensus, so reformatting it would not be a cosmetic patch; it would define a different proof-of-work object. (developer.bitcoin.org)

The community discussion around this tradeoff usually lands in the same place: a larger or relocated nonce may look aesthetically cleaner, but the practical benefit is weak, while the compatibility cost is severe. The Reddit discussion you linked captures that split: some commenters note that a bigger nonce might have been nicer in hindsight, while others point out that miners already solve the problem through coinbase/Merkle-root updates and template-generation logic. (Reddit)

The Correct Mental Model

Do not think of the 80-byte header as “wasting” part of a 128-byte object.

Think of it like this:

Bitcoin consensus object:
80-byte serialized header

First SHA-256 pass:
80-byte message padded to 128 bytes internally

Second SHA-256 pass:
32-byte digest padded to 64 bytes internally

Displayed block hash:
final 32-byte digest, commonly shown reversed from internal byte order

The SHA-256 padding is not part of the Bitcoin header. It is part of the hash function’s internal preprocessing.

Fork Designer’s Note

For a Bitcoin-derived fork, changing block timing, subsidy, retargeting, address prefixes, genesis parameters, or emission math is normal fork territory. Changing the header size or header field order is much deeper. It alters the proof-of-work serialization itself.

For a clean SHA-256 altcoin fork, the conservative path is:

Keep the 80-byte header.
Keep double-SHA-256 header hashing.
Change chain parameters, genesis block, ports, prefixes, subsidy schedule, and branding.
Do not mutate the header format unless you intend to break Bitcoin-compatible tooling and mining assumptions.

The old Bitcoin design is not perfectly elegant. It is compact, durable, ASIC-friendly, SPV-friendly, and deeply baked into consensus. That is why the header is 80 bytes, not 128.