AsicBoost Explained β 13% Free Efficiency
A patented optimization that lets SHA-256 ASICs hash more efficiently by exploiting structural patterns in the Bitcoin block header. The math, the controversy, the legal saga, and why every modern miner β from Bitaxe to S23 β uses overt AsicBoost today.
In 2017, Bitcoin had a quiet civil war. On one side: developers worried that a single mining manufacturer β Bitmain β was secretly using a patented technique to mine more efficiently than anyone else, giving themselves an unfair competitive edge and structurally incentivizing them to produce smaller blocks. On the other side: Bitmain, denying everything while filing patent applications that described exactly the technique they were accused of using.
The technique was called AsicBoost. It was real. It worked. And depending on how you implemented it, it was either a clever protocol-friendly optimization or a quiet attack on Bitcoin's incentive structure. The dispute reshaped Bitcoin mining. By 2026, every modern ASIC ships with AsicBoost enabled by default β but only the "good" version. The "bad" version is dead, and the way it died is itself a story worth telling.
This is the gufo's complete technical guide. We'll cover how AsicBoost actually works at the SHA-256 level, the difference between covert and overt implementations, the patent saga that nearly fractured Bitcoin's mining ecosystem, and why your Bitaxe Gamma in 2026 quietly delivers 13% more hashrate per watt thanks to a fight most miners never noticed.
The SHA-256 trick at the heart of AsicBoost
To understand AsicBoost, you need to understand one specific quirk of SHA-256: the algorithm processes data in 64-byte chunks. When a miner hashes a Bitcoin block header (which is 80 bytes), SHA-256 internally splits it into two chunks β chunk 1 (bytes 0-63) and chunk 2 (bytes 64-79, padded to 64 bytes).
Computing the hash of chunk 1 is expensive. Computing chunk 2 is cheap. Why? Because SHA-256 maintains a "state" between chunks. Once chunk 1 is processed, the state (called a "midstate") is fixed. To hash a different block header that shares the same chunk 1, you can skip the chunk 1 computation entirely and just process chunk 2 against the cached midstate.
Here's where AsicBoost gets clever. The Bitcoin block header is laid out so that:
- Chunk 1 contains: Version (4 bytes), Previous block hash (32 bytes), and the first 28 bytes of the Merkle root.
- Chunk 2 contains: The last 4 bytes of Merkle root, Time (4 bytes), Bits (4 bytes), and Nonce (4 bytes), plus padding.
A traditional SHA-256 miner iterates by changing the Nonce (in chunk 2). Each new nonce requires re-hashing chunk 2 β but chunk 1 stays the same, so its midstate is reused for free. So far so good.
AsicBoost asks a different question: what if you could find multiple chunk 1 inputs that produce useful midstates, and reuse them across many nonce iterations? If you have 4 chunk 1 inputs producing 4 midstates, you can effectively do 4Γ the work in chunk 2 for the same chunk 1 effort. Power consumption drops because the expensive chunk 1 computation runs less often.
The result: Roughly 13-20% less power consumed per hash, depending on how aggressively you implement AsicBoost in silicon. Same hashrate, less heat, lower power bill.
Covert AsicBoost β the controversial version
The first publicly known AsicBoost implementation was covert AsicBoost, also called "Merkle grinding." It works by changing the Merkle root portion of chunk 1 β specifically, the right side of the Merkle tree, which contains transaction hashes.
To find a useful collision (two Merkle roots that share the last 4 bytes but differ in the first 28), the miner shuffles transactions in and out of the block, recomputes the Merkle tree, and looks for the right pattern. Each viable Merkle root gives a new chunk 1 midstate that can be reused.
Why was this controversial?
- It incentivized smaller blocks. Finding viable collisions is faster when the Merkle tree is smaller. A miner using covert AsicBoost has economic motivation to mine smaller or empty blocks, even when transactions are waiting to be included. This is bad for Bitcoin: users pay fees expecting their transactions to be included, and a covert AsicBoost miner has incentive to skip them.
- It interfered with SegWit. SegWit (Segregated Witness) requires a specific Merkle tree structure. Covert AsicBoost was harder to deploy on SegWit blocks, creating a structural conflict between the protocol upgrade and the optimization.
- It was undetectable from outside. A miner using covert AsicBoost looks identical to one not using it. This made it impossible for the network to know who was using it. Suspicion was high; proof was scarce.
- It was patented. The technique was patented by Timo Hanke and Sergio Lerner in 2014. Whoever held the patent had a legal monopoly on the technique. This was the worst case for Bitcoin: a single entity with a 13-20% efficiency advantage that nobody else could legally use.
In April 2017, Bitcoin Core developer Greg Maxwell published a now-famous email titled "ASICBOOST: Bitmain's covert ASIC Bitcoin mining boost." Maxwell argued β with strong technical evidence β that Bitmain was using covert AsicBoost in production, gaining a multi-percent efficiency advantage over competitors, and was using this advantage to oppose SegWit.
Bitmain denied using covert AsicBoost on mainnet. They simultaneously held patent applications describing exactly that capability. The denials were not credible to most observers.
The community response was swift. Greg Maxwell, Adam Back, and others publicly opposed covert AsicBoost. SegWit activated in August 2017 partly through user pressure and the UASF (User Activated Soft Fork) movement. Covert AsicBoost β the controversial form β was effectively neutralized.
Overt AsicBoost β the protocol-friendly version
While covert AsicBoost was tearing up the community, a parallel solution was emerging: overt AsicBoost, also called "version-rolling AsicBoost."
Overt AsicBoost achieves the same SHA-256 efficiency gain by manipulating the version field (the first 4 bytes of chunk 1) instead of the Merkle root. The version field has unused bits β bits that aren't currently used by Bitcoin's consensus rules β and the miner can vary these bits to generate different chunk 1 inputs and midstates.
The key advantages over covert AsicBoost:
- No incentive to produce empty blocks. Version bits are independent of transaction content. A miner using overt AsicBoost has zero structural incentive to skip transactions. Bitcoin's fee market remains intact.
- Compatible with SegWit. Version-rolling doesn't conflict with the SegWit Merkle tree structure.
- Detectable. Anyone watching the chain can see which blocks are being mined with overt AsicBoost (the version field will have unusual bit patterns). Transparency is good for trust.
- More efficient than covert. Counterintuitively, overt is technically more efficient because there's no need to do Merkle tree shuffling to find collisions.
In March 2018, the patent on AsicBoost was opened up under the Blockchain Defensive Patent License (BDPL). Any miner manufacturer could now legally use AsicBoost β but only if they joined the BDPL framework and pledged not to use patents aggressively against others. This was the political masterstroke that defused the entire conflict.
DragonMint's Halong Mining was the first to ship hardware with overt AsicBoost. Slush Pool was the first major pool to support the version-rolling Stratum extension. Bitmain capitulated months later, releasing firmware that enabled overt AsicBoost on the Antminer S9 (which had quietly supported it in hardware all along).
By 2019, overt AsicBoost was the de facto standard. By 2026, you can't buy a SHA-256 ASIC that doesn't support it.
BIP320 β the technical specification
Overt AsicBoost is formally specified in BIP320 (Bitcoin Improvement Proposal 320): "Reduced version-bits availability for general-purpose forks signaling."
BIP320 designates a specific subset of bits in the 32-bit version field as "rollable" β that is, available for AsicBoost manipulation without conflicting with consensus rules. The exact mask is 0x1fffe000 β 16 bits that miners can freely modify, providing 65,536 possible version values per block header.
That's enough variation to drive AsicBoost optimization indefinitely. The miner can iterate through these 16 bits, generating new chunk 1 midstates for each variation, and process many more nonces against each midstate than would be possible without rolling.
Stratum protocol implementation
For AsicBoost to work, the mining pool and the miner have to agree on which version bits the miner is allowed to modify. This requires a Stratum protocol extension.
The extension is called "version-rolling" (or sometimes "mining.configure" in newer Stratum versions). The handshake works like this:
# Miner sends:
mining.configure
extensions: version-rolling
version-rolling.mask: 1fffe000
# Pool responds:
version-rolling: true
version-rolling.mask: 1fffe000
# Now the pool sends jobs WITHOUT specifying full version,
# and the miner is free to iterate over the masked bits. If the pool doesn't support version-rolling, the miner falls back to standard mining (no AsicBoost) and operates at lower efficiency. This is why pool support matters. A pool that doesn't implement version-rolling is leaving 13% of its miners' efficiency on the table.
SoloFury implements version-rolling on every stratum endpoint across all 5 SHA-256 chains (BTC, BCH, BC2, BCH2, XEC). Any AsicBoost-capable miner pointed at any SoloFury server gets the full efficiency gain automatically β no special configuration needed.
Which chips support AsicBoost (2026)
Every modern Bitmain mining chip supports overt AsicBoost natively in silicon:
| Chip | Year | AsicBoost | Implementation |
|---|---|---|---|
| BM1387 (S9) | 2017 | β Hardware-capable | Required firmware patch (2018) |
| BM1397 (S17 / Bitaxe MAX) | 2019 | β | Native, but uses pre-calculated midstates differently |
| BM1366 (S19 XP / Bitaxe Ultra) | 2022 | β | Native via version-rolling register |
| BM1368 (S21 / Bitaxe Supra) | 2024 | β | Native via version-rolling register |
| BM1370 (S21 Pro / Bitaxe Gamma) | 2024-2025 | β | Native, full BIP320 support |
| BM1373 (S23 series) | 2026 | β | Native, full BIP320 support |
MicroBT (Whatsminer) chips have supported overt AsicBoost since the M30 series (2020). Avalon (Canaan) since the A1346 (2022). The technology is universal among modern mining hardware.
For Bitaxe / NerdQAxe / NerdOCTAxe owners running open-source AxeOS firmware: AsicBoost is enabled by default. The firmware negotiates version-rolling with the pool during the stratum handshake. If you're connected to SoloFury, you're using AsicBoost. No configuration required.
The actual efficiency gain β measured, not estimated
Theoretical maximum AsicBoost efficiency gain on SHA-256 is around 20%. Real-world implementations achieve 5-15% depending on how aggressively the silicon is optimized.
Braiins (the team behind Slush Pool and BraiinsOS firmware) verified the Antminer S9's AsicBoost capability in 2018 and measured roughly 13% energy savings in production. Modern chips (BM1370, BM1373) ship with AsicBoost integrated more deeply into the silicon design and achieve similar or slightly better gains.
What does 13% efficiency mean in practice?
| Device | Power without AsicBoost | Power with AsicBoost | Annual savings (US$0.10/kWh) |
|---|---|---|---|
| Bitaxe Gamma (1.2 TH/s) | ~19.5W | ~17W | ~$2.20 |
| NerdOCTAxe (~11 TH/s) | ~170W | ~150W | ~$17.50 |
| Antminer S21+ (235 TH/s) | ~3,750W | ~3,300W | ~$394 |
| Antminer S23 Hyd (580 TH/s) | ~6,250W | ~5,510W | ~$648 |
For an industrial farm running 1,000 S21+ rigs, AsicBoost is worth roughly $394,000 per year in saved electricity. For a single Bitaxe at home, it's a couple of dollars. Either way, the network as a whole is more efficient β and that efficiency comes from a clever observation about how SHA-256 processes its inputs.
The legacy: AsicBoost reshaped Bitcoin's incentive structure
The AsicBoost saga left lasting marks on Bitcoin:
- SegWit was activated. The push to neutralize covert AsicBoost added urgency to SegWit deployment. SegWit then enabled the Lightning Network and other second-layer improvements that have shaped Bitcoin's evolution since 2017.
- The BDPL framework set a precedent. Patent holders in the mining industry now have a structural framework (BDPL) for opening their patents while protecting against aggressive litigation. This has reduced the risk of future patent monopolies in mining hardware.
- Stratum V2 emerged. Among other goals, Stratum V2 is designed to give miners more autonomy in transaction selection β partly as a long-term answer to the centralization risks that covert AsicBoost exposed. We'll cover Stratum V2 in detail in another article.
- BIP320 became standard. Version-rolling is now baseline functionality. Every modern pool and miner speaks it. The technology that almost split Bitcoin in 2017 is now mundane infrastructure.
The owl's takeaway: Bitcoin survived its first major insider-hardware attack, and the response made the entire system stronger. Patent licensing matured. Protocol upgrades activated. Mining became more transparent. The community learned to detect and respond to incentive-misaligned optimizations. None of it was fast or pretty, but the network came out the other side with overt AsicBoost as the universal standard and covert AsicBoost as a historical curiosity.
What this means for your miner today
If you own modern mining hardware (anything from S19 onward, any Bitaxe, any Whatsminer M30+):
- AsicBoost is enabled by default in firmware
- Your pool needs to support version-rolling (BIP320) for the gain to be active. SoloFury does, on all 5 chains.
- Verify it's working: check your AxeOS dashboard (Bitaxe), Bitmain status page (Antminer), or pool stats. AsicBoost-active sessions show "version-rolling: yes" or similar.
- If you switch from a pool that supports version-rolling to one that doesn't, your hashrate stays the same but your power draw increases by ~10-13%. Same work, more energy. Always verify your pool supports version-rolling.
For users of custom firmware (BraiinsOS, VNish, LuxOS): AsicBoost configuration is exposed in the UI and can be tuned per-rig. Most users leave it on default. Power users sometimes adjust the version mask if they're doing experimental work.
The kicker
AsicBoost is one of those quiet engineering optimizations that looks invisible from the outside β your miner runs, your hashrate is what it is, your power bill is what it is β but underneath, billions of additional hashes per second are being computed for free, every second, on every modern ASIC on the network.
The 13% efficiency gain doesn't sound like much until you scale it. Across the entire Bitcoin network at ~750 EH/s, AsicBoost is responsible for roughly 100 EH/s of effective hashrate that wouldn't exist without it. That's more hashrate than the entire network had in 2018. Free, courtesy of a SHA-256 quirk and a patent that almost broke Bitcoin before it ended up making it stronger.
Every block you find on SoloFury β every Bitaxe lottery win, every BCH solve, every XEC subsidy β is partly a product of AsicBoost. Your chip doesn't compute the unnecessary chunks. Your power supply doesn't burn the unnecessary watts. Your block reward arrives just the same.
The math was always there in SHA-256. The community had to fight over how to use it. We fought, we won, and now everyone benefits. That's a quietly remarkable outcome for an open-source money system.
The owl reads the protocol carefully. The owl notices that some hashes share their first 64 bytes. The owl reuses what it can. The owl wastes nothing. So does your ASIC.
Ready to put your AsicBoost-enabled miner to work?
SoloFury supports version-rolling natively on every stratum endpoint across BTC, BCH, BC2, BCH2, and XEC. 1% pool fee. 99% directly to your wallet via coinbase. Sub-50ms latency from Frankfurt, Atlanta, Singapore. Your AsicBoost is wasted on a pool that doesn't speak BIP320 β make sure yours does.
Configure your miner β ASIC chip deep dive β