SHA-256 Midstate

A SHA-256 midstate is the saved internal hash state produced after processing the first 64-byte chunk of a Bitcoin block header. Because SHA-256 ingests data in 512-bit (64-byte) blocks, the 80-byte header splits into a first chunk of 64 bytes and a 16-byte tail. The first chunk — the version, the previous-block hash, and the first 28 bytes of the Merkle root — never changes while a chip sweeps nonces, so its compression is computed once and the resulting 256-bit state is reused for every attempt.

To see why this optimization exists at all, it helps to remember what a miner is really doing: hashing the same 80-byte header billions of times per second, changing only a few bytes at the tail on each attempt. Recomputing the untouched front of that header on every single attempt would be pure waste, and at mining scale even a factor-of-two waste is staggering in absolute terms. The midstate is the elegant answer — compute the fixed part exactly once, freeze the resulting internal state, and then pour all of the silicon's effort into the part that actually changes. It is one of those optimizations that looks like a minor implementation detail from the outside but is in fact woven into the fundamental economics of proof-of-work mining.

What goes in the second chunk

Only the header's tail varies during nonce grinding: the last 4 bytes of the Merkle root, the timestamp, the difficulty bits, and the 4-byte nonce. By caching the midstate — eight 32-bit words, 32 bytes in total — a miner re-runs only the second SHA-256 compression per attempt instead of the full two-block computation, roughly halving the work of the first hash pass. It is a pure, lossless optimization: the result is bit-for-bit identical to hashing the whole header from scratch, so nothing about the block's validity is affected. The chip simply avoids redoing arithmetic whose inputs it knows will not change.

How work is delivered to the chips

This is why a job sent to mining chips is not a literal 80-byte header. The control board typically supplies the 32-byte midstate plus the remaining tail fields, and each chip reconstructs the second chunk internally and sweeps its assigned nonce range. When version rolling (BIP 310, the mechanism behind overt AsicBoost) is active, the board can pre-compute several midstates — one per rolled version value — and hand the chip a small set at once. The chip cycles through them, effectively multiplying its nonce search space, and reports which midstate index produced a candidate so the board can reconstruct the exact winning header.

The AsicBoost connection

The midstate is also the seam that version rolling exploits. Because the version field lives in the first 64-byte chunk, changing it produces a different midstate — and a chip that holds four midstates for four version values can search four times as many header variations without touching its nonce logic. Overt AsicBoost, standardized as version rolling, is simply the disciplined, in-protocol way of doing this, negotiated between miner and pool so the pool knows which version bits the miner may roll. What began as a raw efficiency trick became a documented feature of how modern work is distributed.

Why it endures

The midstate trick predates ASICs entirely: it was already standard in FPGA mining and in the old getwork protocol, where the pool handed out pre-computed midstates directly. Modern Stratum-era hardware computes the midstate on the miner's own control board instead, but the underlying saving is the same one that has made Bitcoin hashing efficient since the CPU-to-FPGA transition. Understanding it demystifies why a miner's job format looks nothing like a raw block header, and it depends directly on the structure described in our Double SHA-256 entry — the two-round hash of the header that every valid hashrate attempt is ultimately racing to satisfy.