Definition
Version is the first field of a Bitcoin block header: a 4-byte (32-bit) number that signals which consensus rules a block follows and, in modern mining, doubles as extra search space for ASICs. It sits at the very front of the 80 bytes a miner hashes.
Also known as: block version, nVersion, the version field.
What the version field does in a block header
The block header is exactly 80 bytes, and the version occupies bytes 0 through 3, ahead of the previous-block hash, the merkle root, the timestamp, the target in compact form, and the nonce. Because the whole header is fed into double SHA-256, every bit of the version directly shapes the resulting hash. Change one bit and you get a completely different output.
Historically the version simply announced which protocol rules a block used. With BIP 9, the upper bits became a signaling channel: miners flip specific bits to vote for or activate a soft fork. Activations like SegWit and Taproot were coordinated this way, with the top bits set to the pattern 0x20000000 to mark a version-bits block.
Version rolling: turning a consensus field into nonce space
The 32-bit nonce alone is a tiny haystack. A modern ASIC chews through all four billion nonce values for a given job almost instantly, then needs fresh work. Version rolling, standardized as BIP 310, lets a miner also vary certain bits inside the version field, dramatically widening the search per job. This is the mechanism behind overt ASICBoost.
In practice the bits from 13 through 28 are treated as rollable, expressed as the mask 0x1fffe000. That is 16 free bits, or 65,536 combinations, layered on top of the nonce. The miner and pool negotiate it during the Stratum handshake: the client sends a mining.configure request advertising the bits it can change, the pool replies with the bits it allows, and the effective mask is the overlap of the two. Submitting a winning share then includes the modified version bits so the pool can rebuild the exact header that was hashed.
Why your ASIC or Bitaxe cares about version
Version rolling is not a luxury feature, it is how today’s hardware stays fed. On Bitmain’s older BM1387 chips, the control board precomputes a handful of midstates, one per version variant, by toggling the low rollable bits, and the chip evaluates them in parallel; the returned result carries a small index telling the firmware which variant produced the hit. Newer chips such as the BM1366 and BM1368 walk the version mask internally and report the exact version bits used in their response frame, so the firmware no longer has to reconstruct them from a midstate index.
For a hobbyist running a Bitaxe or open firmware, the practical takeaway is that the control board increments the version within the negotiated mask, carrying overflow correctly, and hands each variant to the silicon. If version rolling is misconfigured or disabled, a fast chip can exhaust a job before new work arrives, and you see idle time and rejected stale work. You can read the full handshake flow in the Stratum protocol entry, and explore how different builds expose the setting in our firmware comparison. The open-source Bitaxe hub shows the simplest place to watch version rolling work in the open, one more layer of the stack made transparent rather than hidden.
None of this changes the consensus meaning of the field. The pool still controls the base version that signals soft-fork rules; version rolling only borrows the spare bits the network has agreed are safe to toggle. It is a small, elegant reuse of an old header field, and it is what keeps efficient mining honest about which rules each block actually follows.
Related terms: Block header, Nonce, Stratum protocol, Soft fork, Double SHA-256, BM1366
In Simple Terms
A block header field that indicates the block format version and signals support for protocol upgrades.
Version is the first field of a Bitcoin block header: a 4-byte (32-bit) number that signals which consensus rules a block follows and, in modern mining, doubles as extra search space for ASICs. It sits at the very front of the 80 bytes a miner hashes.
Also known as: block version, nVersion, the version field.
What the version field does in a block header
The block header is exactly 80 bytes, and the version occupies bytes 0 through 3, ahead of the previous-block hash, the merkle root, the timestamp, the target in compact form, and the nonce. Because the whole header is fed into double SHA-256, every bit of the version directly shapes the resulting hash. Change one bit and you get a completely different output.
Historically the version simply announced which protocol rules a block used. With BIP 9, the upper bits became a signaling channel: miners flip specific bits to vote for or activate a soft fork. Activations like SegWit and Taproot were coordinated this way, with the top bits set to the pattern 0x20000000 to mark a version-bits block.
Version rolling: turning a consensus field into nonce space
The 32-bit nonce alone is a tiny haystack. A modern ASIC chews through all four billion nonce values for a given job almost instantly, then needs fresh work. Version rolling, standardized as BIP 310, lets a miner also vary certain bits inside the version field, dramatically widening the search per job. This is the mechanism behind overt ASICBoost.
In practice the bits from 13 through 28 are treated as rollable, expressed as the mask 0x1fffe000. That is 16 free bits, or 65,536 combinations, layered on top of the nonce. The miner and pool negotiate it during the Stratum handshake: the client sends a mining.configure request advertising the bits it can change, the pool replies with the bits it allows, and the effective mask is the overlap of the two. Submitting a winning share then includes the modified version bits so the pool can rebuild the exact header that was hashed.
Why your ASIC or Bitaxe cares about version
Version rolling is not a luxury feature, it is how today's hardware stays fed. On Bitmain's older BM1387 chips, the control board precomputes a handful of midstates, one per version variant, by toggling the low rollable bits, and the chip evaluates them in parallel; the returned result carries a small index telling the firmware which variant produced the hit. Newer chips such as the BM1366 and BM1368 walk the version mask internally and report the exact version bits used in their response frame, so the firmware no longer has to reconstruct them from a midstate index.
For a hobbyist running a Bitaxe or open firmware, the practical takeaway is that the control board increments the version within the negotiated mask, carrying overflow correctly, and hands each variant to the silicon. If version rolling is misconfigured or disabled, a fast chip can exhaust a job before new work arrives, and you see idle time and rejected stale work. You can read the full handshake flow in the Stratum protocol entry, and explore how different builds expose the setting in our firmware comparison. The open-source Bitaxe hub shows the simplest place to watch version rolling work in the open, one more layer of the stack made transparent rather than hidden.
None of this changes the consensus meaning of the field. The pool still controls the base version that signals soft-fork rules; version rolling only borrows the spare bits the network has agreed are safe to toggle. It is a small, elegant reuse of an old header field, and it is what keeps efficient mining honest about which rules each block actually follows.
Related terms: Block header, Nonce, Stratum protocol, Soft fork, Double SHA-256, BM1366