ASICBoost is a mining optimization that shares SHA-256 message-schedule computation across suitably prepared block-header candidates. The candidates have a common message component and different midstates; this is not finding two identical final Bitcoin hashes.
Timo Hanke described ASICBoost in a 2016 paper and credited collaboration with Sergio Demian Lerner. The design combines work preparation outside the ASIC with computation organization inside the chip. It changes neither SHA-256 nor the requirement that the final double header hash meet the mining target; it saves some repeated operations. [Timo Hanke — AsicBoost, 2016]
A Bitcoin header is 80 bytes. The first SHA-256 splits it into a 64-byte chunk and the remaining 16 bytes extended with padding. The Merkle root spans both chunks: its last 4 bytes lie in the second alongside time, bits and nonce. This layout explains why the precise positions of changed data matter. [Timo Hanke — AsicBoost, 2016]
Hanke calls suitable jobs colliding work items: they have the same Message and different midstate values from the first chunk. For a selected nonce, the message schedule of the second chunk of the first SHA-256 can be reused across these midstates. This is neither a collision of the complete SHA-256 nor identical first header chunks; those differ. [Timo Hanke — AsicBoost, 2016]
Lerner distinguishes overt, which changes nVersion, from covert, which seeks Merkle roots with the same last 4 bytes and a different first chunk. Covert can use transaction changes or reordering but must preserve valid commitments and dependencies. A varying nVersion alone proves neither a particular saving nor the operator’s identity. [Sergio Demian Lerner — Overt and covert AsicBoost, 2017]
BIP310 uses mining.configure and version-rolling.mask; the response is the intersection of server and miner capabilities. A submission must satisfy version_bits & ~last_mask == 0. The mining.set_version_mask message takes effect immediately, not only at the next job. Version-rolling support thus permits neither arbitrary bit changes nor ignoring a new mask. [BIP310 — Stratum protocol extensions]
At the review date, BIP320 has Draft status and describes 16 general-purpose nVersion bits; BIP323 is also Draft and proposes replacing that with 24 bits. Distinguish these documents from the mask and software actually used on a particular connection. A BIP number alone proves neither universal device support nor arbitrary consensus changes. [BIP320 — General-purpose nVersion bits] [BIP323 — 24 general-purpose nVersion bits]
Hanke’s model gives savings of x × (n − 1) / n, with x the percentage of shared expansion work and n the number of suitable jobs. For x = 25% and n = 4, the result is 18.75%. This models computational work under that assumption, not automatically the same watt saving, price reduction or hashrate increase for every miner. [Timo Hanke — AsicBoost, 2016]
For a specific device, document chip and firmware support, negotiated mask, accepted work and power consumption under comparable operation. Device-level J/TH cannot be replaced by a feature name or theoretical percentage alone. ASICBoost is not a synonym for overclocking and guarantees neither a block discovery nor profit. [Timo Hanke — AsicBoost, 2016] [BIP310 — Stratum protocol extensions]
For the clearest picture, read this entry together with ASIC Miner, Mining, Block header, Proof of Work. The reverse links also lead from Mining Firmware.