Definition
The block header is the compact 80-byte summary of a Bitcoin block that miners hash over and over while searching for a valid proof of work. It is the only part of a block an ASIC ever touches directly: the rest of the block (the transactions) is squeezed into the header through a single 32-byte commitment, so the chip never has to see the megabytes of transaction data behind it.
Every block header contains exactly six fields in a fixed order: version (4 bytes), the previous block’s hash (32 bytes), the Merkle root (32 bytes), the timestamp or nTime (4 bytes), the compact difficulty target or nBits (4 bytes), and the nonce (4 bytes). Together those total 80 bytes. Miners run this header through double SHA-256 and check whether the result falls below the target encoded in the nBits field. When it does, the block is solved.
How the block header maps onto real ASIC hardware
On a working miner, the header is not hashed in one piece. SHA-256 processes data in 64-byte chunks, and the header is 80 bytes, so it splits into two chunks: the first 64 bytes (version, previous-block hash, and the first 28 bytes of the Merkle root) and a final 16-byte tail (the last 4 bytes of the Merkle root, plus nTime, nBits, and the nonce).
The first 64 bytes never change while a chip grinds through nonces, so the control board computes their SHA-256 state once. That precomputed state is called the midstate. Only the 16-byte tail varies, which is exactly the slice the ASIC mutates. This is why a work packet sent to a Bitmain BM1387 or BM1362 chip is not a full 80-byte header at all — it is the midstate (32 bytes) plus the Merkle-root tail, nTime, and nBits. The chip reconstructs the second SHA-256 chunk internally and sweeps the 4-byte nonce field through its search space.
There is a hardware detail that trips up a lot of firmware work: the midstate words are sent to the chip in reverse order, each word big-endian. Get the byte order wrong and the chip happily hashes garbage, returning zero accepted shares even though it is running at full clock. Whether the FPGA computes the midstate itself (as on stock Bitmain firmware) or the CPU computes it and writes it into per-chain work FIFOs (the model open firmware uses) the header-to-midstate split is the same.
Version rolling: mutating the header without touching the nonce
A 4-byte nonce gives only about 4.3 billion combinations — a modern ASIC exhausts that in a fraction of a second. To get more search space, miners also vary the version field of the header, a technique standardized as BIP320 and used by the optimization commonly called AsicBoost. The pool grants a version mask (the standard mask is 0x1FFFE000, covering bits 13 through 28), and the miner is free to flip those bits.
Each distinct version value produces a different first chunk and therefore a different midstate. Mining hardware that supports this sends several midstates per work packet — four is typical — so the chip can hash four header variants in parallel from a single dispatch. When a valid nonce comes back, the firmware has to remember which version variant produced it and reconstruct the exact rolled version before submitting the share to the pool. Reporting the base version instead of the rolled one is a classic cause of valid hashes being rejected.
Why each field matters operationally
The previous block hash is what chains blocks together; it changes the instant the network finds a new block, which is why a miner must drop its current work and switch to fresh templates within milliseconds to avoid wasting hashrate on a stale chain tip. The Merkle root commits to every transaction in the block, so changing the coinbase transaction (or the extranonce inside it) gives the miner a fresh Merkle root and a whole new nonce space to search. The nBits field carries the compact difficulty target — for example the genesis header used 0x1d00ffff, which defines difficulty 1 — and as network difficulty climbs, that target shrinks and a valid header becomes proportionally rarer. The nTime field can be nudged forward slightly to extend the search space, within the consensus rules.
Understanding the block header is the difference between treating a miner as a black box and understanding what the silicon is actually doing. Every accepted share, every rejected share, and every stale-work warning in your dashboard traces back to how these 80 bytes were assembled, split, and hashed. For operators diagnosing low acceptance rates or evaluating firmware, that mental model is the foundation everything else sits on.
If you want a hands-on way to watch headers flow through real hardware, the open-source Bitaxe hub is the friendliest place to start — a single-chip miner that exposes the nBits, nonce, and block data the larger fleets keep hidden. Browse it alongside our open-source mining gear to learn by doing.
Related terms: Block, Merkle Root, Nonce, Proof of Work, SHA-256, Target, Bits, Coinbase Transaction.
In Simple Terms
The 80-byte section of a block that miners hash. Contains version, previous hash, Merkle root, time, target, and nonce.
The block header is the compact 80-byte summary of a Bitcoin block that miners hash over and over while searching for a valid proof of work. It is the only part of a block an ASIC ever touches directly: the rest of the block (the transactions) is squeezed into the header through a single 32-byte commitment, so the chip never has to see the megabytes of transaction data behind it.
Every block header contains exactly six fields in a fixed order: version (4 bytes), the previous block's hash (32 bytes), the Merkle root (32 bytes), the timestamp or nTime (4 bytes), the compact difficulty target or nBits (4 bytes), and the nonce (4 bytes). Together those total 80 bytes. Miners run this header through double SHA-256 and check whether the result falls below the target encoded in the nBits field. When it does, the block is solved.
How the block header maps onto real ASIC hardware
On a working miner, the header is not hashed in one piece. SHA-256 processes data in 64-byte chunks, and the header is 80 bytes, so it splits into two chunks: the first 64 bytes (version, previous-block hash, and the first 28 bytes of the Merkle root) and a final 16-byte tail (the last 4 bytes of the Merkle root, plus nTime, nBits, and the nonce).
The first 64 bytes never change while a chip grinds through nonces, so the control board computes their SHA-256 state once. That precomputed state is called the midstate. Only the 16-byte tail varies, which is exactly the slice the ASIC mutates. This is why a work packet sent to a Bitmain BM1387 or BM1362 chip is not a full 80-byte header at all — it is the midstate (32 bytes) plus the Merkle-root tail, nTime, and nBits. The chip reconstructs the second SHA-256 chunk internally and sweeps the 4-byte nonce field through its search space.
There is a hardware detail that trips up a lot of firmware work: the midstate words are sent to the chip in reverse order, each word big-endian. Get the byte order wrong and the chip happily hashes garbage, returning zero accepted shares even though it is running at full clock. Whether the FPGA computes the midstate itself (as on stock Bitmain firmware) or the CPU computes it and writes it into per-chain work FIFOs (the model open firmware uses) the header-to-midstate split is the same.
Version rolling: mutating the header without touching the nonce
A 4-byte nonce gives only about 4.3 billion combinations — a modern ASIC exhausts that in a fraction of a second. To get more search space, miners also vary the version field of the header, a technique standardized as BIP320 and used by the optimization commonly called AsicBoost. The pool grants a version mask (the standard mask is 0x1FFFE000, covering bits 13 through 28), and the miner is free to flip those bits.
Each distinct version value produces a different first chunk and therefore a different midstate. Mining hardware that supports this sends several midstates per work packet — four is typical — so the chip can hash four header variants in parallel from a single dispatch. When a valid nonce comes back, the firmware has to remember which version variant produced it and reconstruct the exact rolled version before submitting the share to the pool. Reporting the base version instead of the rolled one is a classic cause of valid hashes being rejected.
Why each field matters operationally
The previous block hash is what chains blocks together; it changes the instant the network finds a new block, which is why a miner must drop its current work and switch to fresh templates within milliseconds to avoid wasting hashrate on a stale chain tip. The Merkle root commits to every transaction in the block, so changing the coinbase transaction (or the extranonce inside it) gives the miner a fresh Merkle root and a whole new nonce space to search. The nBits field carries the compact difficulty target — for example the genesis header used 0x1d00ffff, which defines difficulty 1 — and as network difficulty climbs, that target shrinks and a valid header becomes proportionally rarer. The nTime field can be nudged forward slightly to extend the search space, within the consensus rules.
Understanding the block header is the difference between treating a miner as a black box and understanding what the silicon is actually doing. Every accepted share, every rejected share, and every stale-work warning in your dashboard traces back to how these 80 bytes were assembled, split, and hashed. For operators diagnosing low acceptance rates or evaluating firmware, that mental model is the foundation everything else sits on.
If you want a hands-on way to watch headers flow through real hardware, the open-source Bitaxe hub is the friendliest place to start — a single-chip miner that exposes the nBits, nonce, and block data the larger fleets keep hidden. Browse it alongside our open-source mining gear to learn by doing.
Related terms: Block, Merkle Root, Nonce, Proof of Work, SHA-256, Target, Bits, Coinbase Transaction.