Version Rolling Explained: The Header Bits Your Bitaxe Can Flip (BIP 320 & ASICBoost)

Version Rolling Explained: The Header Bits Your Bitaxe Can Flip (BIP 320 & ASICBoost)

Over the last few posts we walked through every place a miner can find "fresh" work to hash. The nonce is the inner loop. The extranonce rebuilds the merkle root when the nonce runs out. nTime can nudge the timestamp inside the rules. There is one more field that modern miners touch, and it is the one most people never notice: the version field. Flipping a small set of agreed bits in that field is called version rolling, and it is closely tied to an idea you may have seen in firmware notes and forum threads — ASICBoost.

The block header's version is a 32-bit field. BIP 320 sets aside 16 of those bits (bits 13–28, mask 0x1fffe000) for miners' general-purpose use. Stratum miners and pools agree on which bits may be rolled through the mining.configure "version-rolling" extension defined in BIP 310. Overt ASICBoost uses that freedom to reuse part of the hashing work across candidate headers. Modern Bitaxe firmware generally supports version rolling — check your firmware notes — and there is nothing to configure by hand. On Bitmern Solo, keep BTC easy-start host btc.bitmernsolo.com with port :3132, username WALLET.worker, password x. Current Effort is not a find guarantee.

This post closes out the search-space series. For the inner hashing loop, read what is a nonce. For coinbase search space, read extranonce explained. For the timestamp lane, read nTime and timestamp rolling. For all six header fields side by side, read the Bitcoin block header explained.

Bitmern Solo is solo infrastructure: flat 1% fee on finds only, you keep 99%. Nothing in this post is financial advice, and nothing here promises a find.

The one-sentence version

Version rolling lets your miner change a reserved slice of the header's version field to get new candidate headers, and ASICBoost is the trick of arranging that work so some of the hashing effort can be shared.

Where the version field sits

The Bitcoin block header is 80 bytes and has six fields. The version is the very first one:

# Field Size Who controls it 1 Version 4 bytes (32 bits) Template sets a base value; miners may roll the BIP 320 bits 2 Previous block hash 32 bytes The chain 3 Merkle root 32 bytes Built from transactions (changes with extranonce) 4 nTime 4 bytes Template, with limited miner rolling 5 nBits 4 bytes The network (difficulty target) 6 Nonce 4 bytes The miner's inner loop

Historically the version number told nodes which block rules a miner followed, and later some of its bits were used to signal readiness for protocol upgrades. That left a lot of the 32 bits doing nothing most of the time — and any change to the header, including a bit in the version, produces a completely different hash. That is the opening version rolling uses.

What BIP 320 actually reserves

If miners started flipping random version bits, nodes and observers might mistake that for upgrade signalling. BIP 320 solves that by formally reserving a range for miners' general-purpose use:

• 16 bits: bits 13 through 28 of the version field
• As a mask: 0x1fffe000

In binary, that mask looks like this — the 1s are the bits miners may roll:

0x1fffe000
0001 1111 1111 1111 1110 0000 0000 0000
   ^                  ^
   bit 28             bit 13

Sixteen rollable bits means 2¹⁶ = 65,536 different version values for the same template. Each one is a brand-new header, and each new header gets its own full 32-bit nonce range. Bits outside the mask stay exactly as the template set them.

How Stratum negotiates it: mining.configure (BIP 310)

Your miner does not just start flipping bits and hope the pool accepts the shares. The Stratum protocol has a handshake for it. BIP 310 defines a mining.configure message, and one of its extensions is version-rolling.

At a high level the conversation goes:

1. Miner → pool: "I'd like to use version-rolling. Here is the mask of bits I want to roll."
2. Pool → miner: "Version rolling is allowed. Here is the mask you may actually use." (The pool can grant all, some, or none of the requested bits.)
3. During mining: when the miner submits a share, it also reports which version bits it rolled, so the pool can rebuild the exact header and check the hash.

EXAMPLE ONLY — simplified, not a literal wire capture

miner:  mining.configure  ["version-rolling"]  mask requested = 0x1fffe000
pool:   version-rolling = true                 mask granted   = 0x1fffe000
miner:  mining.submit ...  + rolled version bits for this share

The important part for you: this all happens between firmware and the pool at connect time. There is no "version rolling" field you need to fill in for the normal Bitmern Solo setup. If the two sides do not agree on version rolling, mining still works — the miner simply leans on the nonce, extranonce, and nTime for its search space.

ASICBoost at a high level

Here is where version rolling turns from "more search space" into "less work per attempt."

SHA-256 does not swallow the whole 80-byte header in one gulp. It processes input in fixed-size chunks, and the header spans two of them. The first chunk holds the version, the previous block hash, and most of the merkle root. The second chunk holds the tail of the merkle root, plus nTime, nBits, and the nonce.

ASICBoost exploits that structure. If a miner can produce several candidate headers that differ in the first chunk but share the same second-chunk inputs, part of the computation on the second chunk can be reused across those candidates instead of being redone each time. Less repeated work per candidate header means more useful attempts for the same effort.

There are two broad ways to get those differing first chunks:

Style How the first chunk varies Visibility Overt ASICBoost Roll the reserved version bits (the version is in the first chunk) Visible on-chain as varying version values — this is what BIP 320 makes clean Covert approaches Search for merkle-root variations with the right properties Harder to see; not something you need to think about for home mining

Version rolling is the overt, above-board route: the bits are reserved, the pool agrees to them, and anyone can see rolled version values in block headers.

We are deliberately not quoting efficiency percentages. How much any particular chip or firmware gains depends on its design, and claims vary. For what actually moves your energy numbers, read Bitaxe efficiency (J/TH).

How version rolling compares to the other search-space levers

Lever Field it changes Who decides the range What it costs to change Nonce Nonce (header) Fixed 32 bits Cheapest — just the inner loop Version rolling Version (header) BIP 320 bits, mask agreed via mining.configure Cheap — no merkle rebuild, and enables work reuse nTime rolling nTime (header) Consensus time rules + pool limits Cheap, but limited room Extranonce Coinbase → merkle root Pool (extranonce1) + miner (extranonce2 size) Requires recomputing the merkle root

None of these levers make a block more likely per hash. Every hash is still an independent lottery ticket. What they change is how cheaply the miner can produce fresh tickets — and ASICBoost-style reuse is about producing them with less repeated work.

What Bitaxe owners actually need to know

1. Modern Bitaxe firmware generally supports version rolling. Check your firmware's release notes if you want to confirm for your exact build. Keep firmware current using a careful process — see the firmware update checklist.
2. You do not configure it by hand. It is negotiated automatically. Your job in AxeOS is still the boring three fields — see AxeOS setup for Bitmern Solo.
3. It is not a luck setting. Version rolling changes how work is generated, not the odds of a single hash meeting the target.
4. Rejected shares are a separate problem. If you see rejects, work through rejected shares fix rather than assuming version bits are to blame.

Current Effort still is not a countdown

Version rolling is one more reason your miner never runs out of things to hash. It does not change what Current Effort means. Current Effort is an attribution and progress signal for the current round — not a find guarantee and not a timer. See Current Effort explained.

A worked picture (EXAMPLE ONLY)

EXAMPLE ONLY — illustrative values, not from a real block

Template base version:   0x20000000
Allowed mask (BIP 320):  0x1fffe000

Rolled candidate 1:      0x20000000   (no rolled bits set)
Rolled candidate 2:      0x20002000   (bit 13 set)
Rolled candidate 3:      0x20004000   (bit 14 set)
Rolled candidate 4:      0x20006000   (bits 13 + 14 set)

Each candidate → different header → different hash
Each candidate → its own full 32-bit nonce range

Notice that only bits inside the mask move. If a share arrived with a bit outside the agreed mask changed, the pool would rebuild a different header than the miner hashed, and the share would not check out.

Checklist: version rolling in practice

1. Keep firmware reasonably current

Symptom: Old firmware, odd behaviour, or features missing compared to release notes.

Fix: Update carefully with a backup first — AxeOS config backup — then follow the firmware update checklist.

2. Set the pool fields correctly

Symptom: Miner connects but no shares appear, or it will not authorize.

Fix:

Host:     btc.bitmernsolo.com
Port:     3132
Username: WALLET.worker
Password: x

Easy-start for BTC on a Bitaxe is :3132.

3. Let negotiation happen

Symptom: You are looking for a "version rolling" toggle.

Fix: There usually is not one to touch. The firmware asks, the pool answers, and mining continues either way.

4. Read logs if you are curious

Symptom: You want to see whether mining.configure happened.

Fix: Your AxeOS logs often show the Stratum handshake. See the AxeOS logs guide.

5. Confirm on the dashboard

Symptom: You changed nothing but want reassurance.

Fix: Open the BTC tab on Bitmern Solo and confirm workers, shares, and hashrate are attributed to your WALLET.worker.

What this post will not invent

• No efficiency percentages for ASICBoost or any specific chip
• No claim that a particular firmware build does or does not roll versions — check its notes
• No hashrate numbers, prices, or ROI
• No financial advice
• No find guarantees; Current Effort is not one either

Common version-rolling misunderstandings

1. "Version rolling means my miner is signalling for an upgrade." No. BIP 320 reserves bits 13–28 precisely so general-purpose rolling is not confused with signalling.
2. "I need to enable ASICBoost in AxeOS." Not for the normal setup. Firmware and pool negotiate version rolling automatically.
3. "Version rolling increases my odds per hash." No. Each hash is still an independent attempt. Rolling changes how cheaply new candidate headers are produced.
4. "ASICBoost is cheating." Overt ASICBoost uses openly reserved bits that the pool agrees to, and the results are visible in headers.
5. "If the pool refuses version rolling, I can't mine." You can. The miner falls back to nonce, extranonce, and nTime.
6. "High Current Effort means rolling will find the block soon." No. Current Effort is not a find guarantee.

Soft next step

Open AxeOS and confirm the three fields: btc.bitmernsolo.com, port :3132, username WALLET.worker, password x. Glance at your firmware notes to see how your build handles version rolling — then leave it alone and let the handshake do its job. Flat 1% on finds only; you keep 99%.

Start mining

Start Mining — after login, open the BTC tab and confirm workers, shares, and hashrate.

FAQ

What is version rolling in Bitcoin mining?

Changing a reserved set of bits in the block header's 32-bit version field to create new candidate headers without rebuilding the merkle root.

What is BIP 320?

The proposal that reserves 16 version bits — bits 13 to 28, mask 0x1fffe000 — for miners' general-purpose use, so they do not collide with upgrade signalling.

What does mining.configure do?

Defined in BIP 310, it lets a Stratum miner and pool agree on extensions. With version-rolling, they agree on which version bits the miner may roll.

What is ASICBoost?

A technique that exploits how SHA-256 processes the header in chunks, so part of the hashing work can be reused across candidate headers. Overt ASICBoost does this by rolling version bits.

Does my Bitaxe use version rolling?

Modern Bitaxe firmware generally supports it. Check your firmware notes for your exact version. You do not need to configure it by hand.

What does Bitmern Solo charge?

A flat 1% fee on finds only — you keep 99%.

Does Current Effort mean I am about to find a block?

No. Current Effort is an attribution signal — not a find guarantee. See Current Effort explained.