Midstate: SHA-256 Hashing Optimization

Midstate is an intermediate SHA-256 state that hardware computes once and reuses while the start of the header stays still. It appears in no Bitcoin protocol field: it is an internal optimization, but one that explains a share of rejected shares when it is mishandled.

SHA-256 works in 64-byte blocks

SHA-256 does not consume 80 bytes in one go. It processes the message in 64-byte blocks, updating an internal state of eight words. Since a block header is 80 bytes, the first message block is the first 64 bytes of the header, and the second holds the remaining 16 bytes plus the padding the function requires.

Those first 64 bytes hold the version, the previous block hash, and the start of the Merkle root. They do not change while only the nonce rolls, because nonce, nBits, and nTime sit in the tail of the header, so in the second message block.

Midstate is precisely the internal state after absorbing that first 64-byte block. It is computed once for a header whose head is frozen, after which each nonce try resumes only the second compression, then the second SHA-256 of the double hash.

The final digest is identical to a full recomputation. So this is not a cryptographic shortcut, but the factoring out of repeated work.

Why miners use it

Without midstate, every try would replay the first 64-byte block even though it never changed. With it, silicon spends its tight loop on the part that varies. On an ASIC this is normal operation: cores receive a midstate and a header tail, not a full 80 bytes on every tick.

Three consequences in operation:

• Repeated work disappears while Merkle root, prevhash, and version stay stable.
• Midstate expires instantly as soon as the Merkle root changes, whether from a new extraNonce, a new template, or a different coinbase. It has to be recomputed before the nonce runs again.
• A midstate inconsistent with the job produces hashes matching no real header. The pool then rejects the shares while local hashrate still looks flattering. This is one of the cases where the gap between local and pool hashrate comes from neither the network nor the hardware.

Midstate never appears in a published block. A node rechecks the double SHA-256 of the full 80 bytes, so a wrong midstate simply produces no valid hash at all.

What it does not change

Reusing an intermediate state alters neither the target, nor the difficulty, nor the chance that a random hash falls under the target. It only changes how much redundant work the circuit skips. Midstate is therefore not a yield lever, and a vendor presenting it as one would be describing the normal behaviour of any ASIC.

Search modes that vary certain header fields to keep a midstate alive longer belong to a different subject, covered on the ASICBoost page.

What it looks like on a healthy machine

1. The job arrives with prevhash, Merkle branches, nBits, nTime, and coinbase.
2. Firmware builds the header, computes the midstate, and pushes the batch to the chips.
3. The chips sweep the nonce, and sometimes other allowed bits.
4. A new job, or an extraNonce that changes the Merkle root, invalidates the midstate, and the cycle restarts at step 2.

If you are debugging rejected shares, there is no midstate option to hunt for in an interface. Look first at the template received and at the controller clock: a midstate is valid for exactly one header prefix, and anything that shifts that prefix makes it unusable.