ASICBoost: Hardware Mining Optimization

ASICBoost names a family of SHA-256 work reorderings on the block header, meant to reuse a midstate longer while exploring candidates. Consensus takes no account of it: a block is valid only if it meets node rules, shared midstate or not.

The problem it aims at

SHA-256 over 80 bytes has an exploitable shape: the first 64 bytes of the header can be absorbed once and for all, which gives the midstate, and only the tail changes with the nonce. While the head is fixed, that is already how any ASIC operates.

ASICBoost, in the original idea published by Timo Hanke and later discussed across the industry, looks for prefix collisions: several different headers whose first-absorbed part leads to the same intermediate state, which lets more work be shared across tries. You then explore more candidates for the same prefix cost, provided silicon and firmware are built for that mode.

The target does not move and SHA-256 is not weakened. What changes, at best, is the internal cost of some tries.

Overt and covert

Two broad approaches were described in the public debate. These are names from the literature, not checkboxes in an interface.

Overt. You lean on fields the protocol already lets you vary in the open, typically version bits in the header, inside a window nodes accept. The published block shows those choices, and an observer can see that version was rolled. It is aggressive use of an existing lever.

Covert. You arrange block contents, often around the Merkle root and the order of the data feeding it, so that header prefixes lend themselves to midstate sharing, without the pattern being as readable as a version mask. The block stays an ordinary block: transactions, coinbase, Merkle root. The optimization intent appears in no protocol field.

That invisibility is what fed the debate on neutrality and detectability. Neither approach lets a hash above the target through: a node rechecks the double SHA-256 without caring how it was found.

Why it mattered

In the late 2010s the topic became political as much as technical:

• patent and licensing around the overt idea, and the fear that a method would stay reserved to certain vendors;
• apparent fairness of proof-of-work if part of the fleet could hash more cheaply for the same useful try;
• proposals to change rules, for example tightening version bits, to make the overt path less comfortable;
• public confusion between circuit optimization and an attack on Bitcoin.

For the operator, the lasting lesson is not a percentage advantage. It is that firmware and silicon can organize the same puzzle differently, and that the network judges only the final hash and the block rules.

Version rolling: what you can actually check

The concrete legacy of ASICBoost in an ordinary operation is the version rolling negotiated between the machine and the pool. The miner asks the pool for permission to vary certain version bits, and the pool answers with a mask that delimits exactly which bits are allowed, often 0x1fffe000.

What to do with that:

• Check in the miner logs that the negotiation succeeded, and note the mask the pool granted.
• Make sure firmware rolls version inside that mask. Rolling outside it produces a stream of rejected shares, with local hashrate that still looks fine and pool hashrate that drops away.
• Re-check after any pool change: not every pool grants the same mask, and some refuse the negotiation entirely.

If a vendor today promises an "ASICBoost mode" presented as a yield, ask for three things before believing it: what the mode actually changes in the job, whether your pools accept the shares and blocks produced, and a measurement taken on your own floor rather than a slide.

One clarification that heads off a common confusion: classic midstate, meaning one fixed header head and many nonces, is not ASICBoost. ASICBoost names the search for sharing beyond that trivial case.