ASICBoost

Imagine processing similar orders: you prepare their shared information once, but still finish each order separately. This is a useful analogy for ASICBoost. Timo Hanke described it in 2016, acknowledging his collaboration with Sergio Demian Lerner. An ASIC is a chip built for a particular computational task; reorganizing its work can avoid needless repetition. It changes neither SHA-256, the hash function used, nor Bitcoin network rules. The final double hash of the header must still be no greater than the target, and the whole block must be valid. [1]

A byte is a unit used to measure the size of digital data. A header is a compact summary of a block. It occupies 80 bytes, while the first hashing pass processes 64 bytes followed by the remaining 16 and the prescribed padding. The Merkle root, the combined fingerprint of the transactions, crosses that boundary: its final 4 bytes are in the second part. Alongside them are the time, bits, the compact encoding of the mining target, and nonce, the counter varied between attempts. Which fields change therefore determines which calculations can be reused. [1]

Hanke calls suitable sets colliding work items. Their first header chunks differ and therefore produce different midstate values, the intermediate computation states. The part called Message stays the same. For a chosen nonce, the chip can share the message schedule, a set of auxiliary values used to process the second chunk of the first SHA-256. Computation then continues separately from each intermediate state. This is neither a discovery of identical final hashes nor a broken hash function. Here, collision means matching a selected part of the input; the first header chunks differ. [1]

Sergio Demian Lerner distinguishes overt and covert ASICBoost. Overt changes permitted bits in nVersion, the header version field, so preparation need not search for a partial Merkle root match. Covert does search for one: the final 4 bytes of the Merkle root stay the same while its first part changes. Permissible transaction data or transaction ordering can be varied, but transaction dependencies must be respected and the recorded fingerprints must still match the block’s data. Observing different header versions alone does not establish an energy saving or identify the operator. [2]

A pool coordinates miners’ work. Its server, the computer service the device communicates with, accepts results under the agreed conditions. Peter’s machine cannot alter the header arbitrarily. The document numbered BIP310 describes negotiation through mining.configure: version-rolling.mask identifies changeable bits, and the response selects the intersection of the miner’s and server’s capabilities. A mask is a map of permitted positions, not a promise of greater speed. The technical condition version_bits & ~last_mask == 0 requires submitted bits to stay within the last valid mask. A mining.set_version_mask notification takes effect immediately, without waiting for the next job. Firmware, the software controlling the device, must follow that agreement. [3]

BIP320 proposes 16 general-purpose nVersion bits; BIP323, its proposed replacement, describes 24 bits. At this editorial review both documents have Draft status. That label alone means neither that nothing is implemented nor that every pool supports it. The document describes intended uses of the field; an actual connection depends on its current mask and software. Peter therefore cannot infer his device’s permissions from a BIP number or treat a proposal as an automatic change to network rules. [4] [5]

Hanke expresses the modelled saving as x × (n − 1) / n. Here x is the share of computation that can be reused, and n is the number of suitable work items. With x = 25% and n = 4, the result is 18.75%. Instead of repeating the shared preparation for every item, the machine does it together. The result describes this computation model, not automatically the same reduction in watts for any device. Other circuits consume energy too, and operating conditions affect consumption. It cannot simply be copied into a performance or revenue forecast. [1]

Peter first checks chip and firmware support and cooperation with the pool. He then checks that the pool accepts the work and measures the whole device under comparable conditions. J/TH means joules per terahash: the energy needed for a trillion hashing attempts. Comparisons must cover the same device components and the same measurement period. The ASICBoost label cannot replace that measurement. It is not a synonym for overclocking, which increases operating frequency, and it guarantees neither a discovered block nor a profit. It is a way to perform some work more efficiently when the complete setup supports it. [1] [3]