mining bip asics

Bitcoin's 24-Bit Mining Nonce Proposal: Why ASICs Need More Headroom

Bitcoin Index · · 7 min read
Bitcoin's 24-Bit Mining Nonce Proposal: Why ASICs Need More Headroom

A top-tier Antminer S21 XP Hydro, churning out 473 terahashes per second, exhausts Bitcoin’s entire 32-bit nonce space in under 10 microseconds. Not milliseconds. Microseconds.

That’s the problem Matt Corallo’s new BIP proposal aims to fix. By expanding the nVersion nonce space from 16 bits to 24 bits, the draft specification would give modern mining hardware room to breathe without forcing controllers to constantly rebuild block templates.

This isn’t a consensus change. It’s a specification update that acknowledges reality: Satoshi’s 32-bit nonce, perfectly reasonable for CPU mining in 2009, has become a bottleneck in the age of exahash-scale mining.

The Speed Problem

When Bitcoin launched, an Intel Core i7 3930K could hash at about 66.6 MH/s. At that rate, cycling through all 4.3 billion possible nonce values took over a minute. Plenty of time.

Fast forward to March 2026. The network hash rate hovers around 1,000 EH/s, and individual ASICs have become computational monsters:

  • Antminer S21 XP Hydro: 473 TH/s (exhausts nonce in ~9 microseconds)
  • Whatsminer M66S: 298 TH/s (~14 microseconds)
  • Antminer S21 Pro: 234 TH/s (~18 microseconds)

The ASIC controller must constantly feed fresh work to mining chips, creating a severe bandwidth and CPU bottleneck.

Current Workarounds: extraNonce and Version Rolling

Miners have developed two main strategies to extend the search space beyond 32 bits.

extraNonce in the coinbase transaction: When the nonce field is exhausted, miners modify arbitrary data in the coinbase transaction’s scriptSig field. This changes the coinbase transaction hash, which alters the Merkle root, giving miners an entirely new set of 2^32 nonce values to try.

The problem? This requires the controller to rebuild the Merkle tree, compute a new root, and distribute fresh headers to all chips. With modern ASICs exhausting nonces in microseconds, this creates constant overhead.

Version rolling (BIP 320): Introduced in 2018, BIP 320 reserves 16 bits of the block header’s nVersion field for “general purpose use,” primarily as additional nonce space. This provides 65,536 different nVersion values to roll through, multiplying the effective search space and reducing extraNonce update frequency.

But 16 bits only delays the problem. For a 234 TH/s Antminer S21 Pro, even with version rolling, the combined 48-bit space (32-bit nonce + 16-bit nVersion) is exhausted in about 1.2 seconds. Better than 18 microseconds, but still problematic at scale.

The Emerging Threat: nTime Rolling

Recent evidence shows some mining hardware has resorted to an even more concerning workaround: rolling the nTime field.

According to discussions in the Stratum v2 specification repository, the BZM2 ASIC (formerly Intel) rolls 7 bits of nTime for extra search space, treating the timestamp field as additional nonce space instead of incrementing it every second as intended.

This is bad for three reasons:

1. Difficulty adjustment bias: If widespread, aggressive nTime rolling causes timestamps to drift ahead of real time on average. Even if each block remains valid individually, the cumulative effect across many blocks could subtly bias the difficulty adjustment downward.

2. Consensus risk: Bitcoin consensus rules allow blocks with timestamps up to 2 hours in the future. Rolling 12 bits would consume this entire window (2^12 = 4,096 seconds). Rolling 13 bits would risk generating invalid blocks. As Matt Corallo noted in the Stratum v2 discussion, “You might generate an invalid block.”

3. Great Consensus Cleanup compatibility: The proposed Great Consensus Cleanup (BIP 54) imposes new minimum time limits for blocks at difficulty adjustment boundaries. While forward-rolling nTime should remain compatible, relying on it as nonce space is fundamentally fragile.

The Proposed Solution: 24-Bit nVersion Space

Corallo’s draft BIP, posted to the Bitcoin-Dev mailing list on February 26, 2026, proposes expanding the nVersion nonce space from 16 bits to 24 bits.

Technical specification:

  • Current (BIP 320): Bits 13-28 reserved (16 bits)
  • Proposed: Bits 5-28 reserved (24 bits)
  • New mask: 0x1fffffe0
  • Result: 2^24 (16,777,216) nVersion values, 256× more than BIP 320

For that same 234 TH/s Antminer S21 Pro:

  • 32-bit nonce only: ~18 microseconds
  • 32-bit nonce + 16-bit nVersion (BIP 320): ~1.2 seconds
  • 32-bit nonce + 24-bit nVersion (proposed): ~5 minutes

The controller transforms from a microsecond-scale bottleneck into a component that can efficiently manage mining chips with far less bandwidth and CPU overhead.

From the draft:

“BIP 320 defined 16 bits of nVersion as nonce space for additional nonce space. It turns out that this isn’t enough, as some devices have started using 7 bits from nTime for extra nonce space. Given there’s limited utility in the additional nVersion bits for use in soft fork signaling, instead here we offer 24 bits of nVersion space as extra nonce space.”

This prioritizes mining efficiency while leaving 8 bits (bits 0-4 and 29-31) for soft fork signaling. Bitcoin rarely deploys multiple simultaneous soft forks, and alternative signaling mechanisms exist when needed.

Headers-Only Mining Benefits

The proposal particularly benefits “headers-only mining,” a widely deployed approach where ASICs receive only block headers from controllers, avoiding the need for mining firmware to handle transaction validation, Merkle tree construction, and other consensus logic.

From the draft:

“Headers-only mining avoids mining devices (either ASICs or the firmware) from having to concern itself with the vast space of consensus logic (handling transactions, merkle trees, etc). It is widely deployed in ASICs, but requires a substantial number of jobs fed across an entire device, keeping the ASIC controller busy. Providing additional nonce space for the ASICs to roll without needing fresh work from the controller may simplify ASIC design somewhat.”

Adoption Timeline and Compatibility

This is a specification-level change, not a consensus change. It requires no soft fork or network upgrade, just coordination between mining pools, firmware developers, and node software maintainers.

For pool operators: Pools using the Stratum protocol already negotiate version-rolling masks with miners. The change from BIP 320’s mask to the new mask is straightforward. Pools will need to update Stratum server software and ensure compatibility with miners using older firmware.

For ASIC manufacturers: Firmware updates will recognize and utilize the expanded 24-bit space, reducing extraNonce update frequency and optimizing header-only workflows.

For node operators: Bitcoin Core and other full node implementations will need to update their BIP 9 logic to ignore bits 5-28 when interpreting soft fork signals, preventing false warnings about “unknown soft fork activations.”

The proposal was discussed in Bitcoin Optech Newsletter #395 on March 6, 2026, just two days after the latest update to GitHub PR #2116.

Historical Perspective

The evolution of Bitcoin mining shows why this matters:

EraHardwareHash RateTime to Exhaust 32-bit Nonce
2009-2010CPU (Intel Core i7)~66 MH/s~65 seconds
2010-2013GPU (AMD Radeon 5850)~430 MH/s~10 seconds
2013-2015Early ASIC (Antminer S1)~180 GH/s~24 milliseconds
2018-2020Mid-gen ASIC (Antminer S9)~14 TH/s~0.3 milliseconds
2025-2026Current-gen (S21 XP Hydro)~473 TH/s~9 microseconds

Network hash rate has grown from megahash to exahash:

  • 2010: ~10 MH/s
  • 2014: ~100 TH/s
  • 2018: ~40,000 TH/s
  • 2022: ~200 EH/s
  • 2026: ~1,000 EH/s

Satoshi’s 32-bit nonce, sufficient for solo CPU miners in 2009, now represents less than 10 microseconds of work for a single modern ASIC.

Will 24 Bits Be Enough?

For a hypothetical 1 PH/s (1,000 TH/s) ASIC, the combined 56-bit space (32-bit nonce + 24-bit nVersion) would still provide about 4.3 seconds before exhaustion. Even if the network hash rate grows 10× to 10,000 EH/s, the approach remains manageable.

Assuming continued efficiency gains (J/TH improvements) rather than pure hash rate increases, 24 bits should remain viable for the foreseeable future. If necessary, future proposals could expand further, but at some point the tradeoff between nVersion signaling space and nonce space becomes critical.

The Bottom Line

This proposal represents a pragmatic response to the relentless growth of Bitcoin’s hash rate. By providing miners with 256× more header-only search space, it addresses an emerging problem before it becomes widespread and potentially harmful to difficulty adjustment and consensus safety.

The proposal:

  • Supersedes BIP 320 with a larger nonce space
  • Prevents nTime abuse by giving miners sufficient nVersion headroom
  • Simplifies ASIC design by reducing controller overhead
  • Requires no consensus change, just coordination among pools, miners, and node software

For mining pool operators and hardware manufacturers, the message is clear: the 16-bit era is ending. Adoption will likely come quickly because this is a pure efficiency improvement with no downside for miners.

Matt Corallo caught the nTime rolling problem early, before it could become widespread. That kind of proactive maintenance is how Bitcoin scales without compromising the fundamental soundness of its consensus rules.

The network is approaching zettahash-scale mining. Solutions like this ensure Bitcoin’s Proof-of-Work mechanism can scale efficiently into that future.

Sources