Bitcoin Block Header: Structure and Fields

The block header is the only object the machine hashes in a loop. The rest of the block, transactions, signatures, and scripts, enters proof-of-work only as a 32-byte summary: the Merkle root. Understanding the header, the nonce, and the extraNonce amounts to understanding what a miner actually does.

What the header holds

A Bitcoin header is 80 bytes. In the usual protocol order:

• block version;
• previous block hash, which forms the chain link;
• Merkle root of this block's transactions;
• timestamp, or nTime;
• nBits, the compact form of the difficulty target;
• the nonce, a 32-bit field.

The network accepts a block if the double SHA-256 of those 80 bytes is numerically below the target decoded from nBits. There is no other work criterion on the header, and no known method for computing the right nonce other than trying it.

An operator never assembles this header by hand. The pool, or the node when solo, supplies the stable job fields; firmware lays them down, rolls the nonce, and changes something else when it has to.

The header nonce

The nonce is a 32-bit integer, about four billion values. Each value yields a different header, hence a different hash. A modern ASIC walks that space in a fraction of a second, which has a direct consequence: the nonce alone can no longer keep the machine fed.

When the space is exhausted, another header field has to change, or the machine re-hashes the same 80 bytes indefinitely.

extraNonce: more space without touching the protocol

The header provides no second nonce. Established practice puts an extraNonce inside the coinbase transaction, the first in the block, the one that creates the reward and often carries a miner message.

Changing the extraNonce changes the coinbase, so that transaction's hash, so the Merkle root, so the 80 bytes of the header. The miner recovers an entirely fresh nonce space without altering a single consensus rule.

In a pool, the classic Stratum v1 scheme splits that lever:

• the pool sends coinbase parts and Merkle branches;
• firmware, or a proxy, inserts an extraNonce of its own;
• it rebuilds the root, then sweeps the header nonce.

Two machines on the same pool must never explore the same extraNonce and nonce pair on the same job. The pool allocates distinct ranges for exactly that reason, and a bad allocation shows up directly as duplicate shares.

nTime, version, and the imposed fields

Two other fields can move within strict limits:

• nTime shifts inside a window around network time. Too far ahead or behind and the block is rejected. Inside the window, stepping one second renews the header as effectively as a new starting nonce.
• version accepts, on some jobs, a bit mask negotiated with the pool. It is an additional search-space lever, bounded by the node's rules.

nBits and the previous block hash are imposed by the current chain. No setting applies to them.

What this means in operation

Useful work means producing double SHA-256 hashes of candidate headers until you meet either the pool's share target or the network target. The transaction list is not re-hashed on every try: it stays fixed in the Merkle root until the coinbase, the extraNonce, or the template changes.

Three concrete consequences:

• A stale job makes the current space worthless. Latency to the new template therefore weighs more on your revenue than any supposedly lucky nonce.
• A badly managed extraNonce, with worker collisions or an incomplete template, produces orphan shares that never appear anywhere as credit.
• Midstate, covered on another page, is only an internal optimization: the first bytes of the header do not change on every nonce.

Finding a valid nonce stays a draw in a huge space, under a target the network retunes every 2016 blocks. No firmware computes the solution faster; it tries more headers per second, or the same headers with fewer losses. Those losses, not luck, are the part you can act on.