Version Rolling (BIP 310)

Version rolling is a mining technique that treats reserved bits of the block header's nVersion field as an additional source of variation. By cycling through allowed version bits, hardware effectively multiplies the search space it can explore per nonce range, which is the mechanism behind overt ASICBoost. Standardizing how miners and pools agree on which bits may be rolled is the job of BIP 310.

What BIP 310 actually defines

Authored by Pavel Moravec and Jan Capek in March 2018, BIP 310 introduces a generic extension-negotiation framework for the Stratum protocol via a mining.configure message. Its flagship extension is version-rolling: the miner advertises a mask of bits it wants to change and a minimum bit count, and the server replies with the intersection of bits it permits. From then on, share submissions carry a version_bits value. This solved a real gap, because the original Stratum protocol had no way for a miner to communicate a changed block version back to the server.

BIP 310 versus BIP 320

BIP 310 negotiates the mechanism; BIP 320 defines which sixteen header bits (positions 13 to 28) are reserved for general use and masked out of soft-fork signaling. Together they let version rolling coexist safely with future protocol upgrades. The two specifications grew directly out of the industry's move to make ASICBoost overt and detectable on-chain.

For the efficiency trick this enables, read our ASICBoost entry; for the protocol carrying the negotiation, see Stratum V1.

The Wire Protocol in Detail

The negotiation is a single exchange at connection setup. The miner's mining.configure lists the extension version-rolling with two parameters: version-rolling.mask, the header bits it wants permission to change (conventionally 1fffe000 — bits 13 through 28), and version-rolling.min-bit-count, the minimum number of rollable bits the hardware needs to be useful. The server answers with its own mask, and the miner may roll only the intersection of the two. From then on, every mining.submit carries a sixth parameter, version_bits — eight hex characters containing only bits inside the negotiated mask — and the pool reconstructs the final header version by splicing those bits into the job's version field. Pools can even update the mask mid-session with a mining.set_version_mask notification.

Why Hardware Wants It: The Nonce Is Too Small

A block header's nonce field is 32 bits — about 4.3 billion values — which a modern ASIC exhausts almost instantly at terahash speeds. Without more entropy, the machine would starve waiting for new work. Version rolling opens 16 additional header bits, multiplying each work unit's search space by 65,536, and it does so in the header's first 64 bytes. That placement is the ASICBoost connection: SHA-256 processes the header in chunks, and varying bits in the first chunk lets hardware precompute multiple midstates and reuse work across candidates — the overt, on-chain-visible form of the optimization. BIP 320 complements BIP 310 by reserving exactly those sixteen bits (13–28) so rolled versions never collide with soft-fork signaling.

Version Rolling Across Protocol Generations

Under Stratum V1, version rolling is a bolted-on extension that both ends must negotiate — and a proxy in the middle must faithfully relay. Stratum V2 absorbed the lesson: the capability is native, signaled by a version_rolling_allowed flag in extended mining jobs and a device requirement flag at connection setup, with no side-channel negotiation. Practically speaking, every current ASIC and pool supports version rolling under V1 — a miner that cannot roll version bits forfeits real throughput on modern hardware — and firmware stacks treat it as baseline plumbing. It is a rare example of a mining optimization that began as a controversy (covert ASICBoost) and ended as an open, standardized efficiency everyone shares.