New BIP Proposes 24-Bit nVersion Nonce Space to Fix Mining Header-Only Problem

Bitcoin’s mining ASICs have become so powerful that they’re running into a fundamental limitation: they can exhaust the 32-bit nonce field in under 200 milliseconds. Miners adapted by rolling bits in the nTime field to get more search space, but this creates problems with timestamps and difficulty adjustment. Now, Bitcoin Core developer Matt Corallo has proposed expanding the nVersion nonce space from 16 bits (BIP 320) to 24 bits, giving miners 256 times more headroom without touching nTime.

The nonce space problem

A Bitcoin block header is an 80-byte structure containing six fields: nVersion, the previous block hash, merkle root, nTime (timestamp), nBits (difficulty target), and a 4-byte nonce. When mining, ASICs hash this header repeatedly, incrementing the nonce each time, searching for a hash below the difficulty target.

With 32 bits, the nonce provides roughly 4.3 billion possible values. Modern ASICs exhaust this space in fractions of a second.

According to BIP 320 and Stratum v2 discussions, mining devices above 280 TH/s “outrun true time” when rolling nTime. Current-generation ASICs far exceed this: the Antminer S23e U2H delivers 865 TH/s, and Antoine Poinsot notes some chips now perform over 1 PH/s.

When the nonce space is exhausted, miners need additional search capacity. Traditionally this came from the extraNonce in the coinbase transaction (which requires recalculating the merkle root) or from rolling the nTime field within valid bounds. The problem: some deployed hardware has started rolling 7 bits of nTime as extra nonce space, according to Stratum v2 specification discussions.

Why rolling nTime is bad

Rolling nTime for nonce purposes creates several issues. First, it causes timestamp drift. Aggressive nTime rolling causes block timestamps to drift ahead of real time on average. Even if each individual block remains valid (within the 2-hour MAX_FUTURE_BLOCK_TIME consensus rule), the cumulative effect across many blocks biases the difficulty adjustment downward. The algorithm uses timestamps to estimate how long a 2016-block period took. If timestamps systematically run ahead, the algorithm thinks mining is going faster than it actually is and adjusts difficulty incorrectly.

Second, there’s limited headroom. Bitcoin consensus constrains nTime in two ways: it must be greater than the median of the past 11 blocks, and cannot be more than 2 hours in the future. With 7 bits of rolling you use 128 timestamp values. Roll 12 bits (4096 values) and you approach the 7200-second limit. Roll 13 bits and you risk generating invalid blocks.

Third, aggressive nTime rolling creates future consensus conflicts. BIP 54 (Consensus Cleanup) proposes fixes for the timewarp attack by imposing minimum time limits at difficulty adjustment boundaries. While the grace period was increased to 2 hours specifically to accommodate nTime rolling, aggressive use of nTime for nonce space constrains future consensus rule design.

The solution: more nVersion bits

Corallo’s proposal expands the nVersion nonce space from 16 bits to 24 bits. This reserves bits 5-28 inclusive (mask 0x1fffffe0) for general-purpose use. Nodes applying the updated rules use a mask of 0xe000001f when checking nVersion, effectively ignoring bits 5-28 for soft fork signaling.

With 32 bits from nonce plus 24 bits from nVersion, miners get 56 bits of search space per job, or roughly 72 quadrillion combinations.

Poinsot calculated that the current 16-bit space allows serving fresh jobs to an ASIC once per second up to approximately 280 TH/s. The additional 8 bits extend this limit to about 72 PH/s without needing to roll nTime at all. For context, individual ASICs currently top out around 1 PH/s. The proposal provides substantial headroom for device scaling.

Headers-only mining architecture

Modern mining hardware uses a “headers-only” architecture where ASIC chips only hash the 80-byte block header. They never see transactions, merkle trees, or other consensus logic. This simplifies chip design and maximizes SHA-256 hashing performance.

The mining controller (firmware or separate CPU) handles the complex Bitcoin logic: validating transactions, building candidate blocks, calculating merkle roots, and communicating with pools. The controller feeds many different header templates to the chips, each with different extraNonce values and thus different merkle roots.

The bottleneck: generating new templates requires recalculating the merkle root, which is computationally expensive relative to modern ASIC hashing speeds. If ASICs exhaust their search space in under 200ms, the controller must generate and distribute 5+ new templates per second to each chip.

By expanding nVersion nonce space, ASICs can run longer on each template, reducing controller workload and bandwidth requirements.

Impact on soft fork signaling

BIP 9 and BIP 8 repurposed nVersion as a bitfield for coordinating miner-activated soft forks. Before BIP 320, 29 bits were potentially available for signaling (bits 0-28, excluding the top 3 bits reserved by BIP 9). After BIP 320, 13 bits remained. After this proposal, only 5 bits remain.

Is 5 bits enough? Probably. Bitcoin soft forks have become increasingly rare and carefully considered. Five concurrent soft fork proposals would be unprecedented. More importantly, as the proposal notes, “given that a non-trivial percentage of the hashrate is already making uses of those bits, future soft forks SHOULD NOT utilize those bits for activation signalling.” Those 24 bits are effectively lost for signaling purposes already because miners are using them.

Backward compatibility

Technically, this changes consensus rules. Non-upgraded nodes might interpret the newly reserved bits as potential soft fork signals. However, the proposal argues this is not a practical concern because miners are already using these bits (via nTime rolling). No pending soft fork proposals use bits 5-28, and any that tried would conflict with existing mining hardware practices.

The proposal doesn’t require a traditional soft fork activation. It documents and formalizes existing practice while updating soft fork activation specifications to exclude these bits.

What BIP 320 got right (and wrong)

BIP 320, written by BtcDrak in 2018, recognized that nVersion had more capacity than needed for versioning and soft fork signaling. It reserved 16 bits for general purpose use, primarily targeting extra nonce space and version-rolling AsicBoost (which requires 2 bits for 4-way collisions).

In 2018, 16 bits seemed sufficient. But ASIC technology advanced faster than expected. By 2025-2026, 16 bits proved inadequate. The evidence: miners started rolling nTime bits despite the problems this creates.

Context from Stratum v2

The Stratum v2 discussion provides context for why this proposal emerged in March 2026. Stratum v2 attempted to spec out nTime rolling behavior for Standard Channels, noting that miners with hashrate above 280 TH/s would need to roll nTime faster than once per second.

During a February 26, 2026 working group call, the discussion surfaced that BZM2 ASICs are already rolling 7 bits of nTime, that there’s a mathematical limit to safe nTime rolling (about 12 bits before risking invalid blocks), and that Matt Corallo questioned compatibility with Consensus Cleanup proposals.

Corallo’s BIP proposal, submitted the same day as that working group call, represents the “reserve more nVersion bits” path forward.

Why this matters

This might seem like technical minutiae, but it reflects important principles in Bitcoin development.

The proposal represents pragmatic consensus. It doesn’t fight miners using these bits. It formalizes and optimizes existing practice.

It acknowledges mining hardware reality. Bitcoin Core development must consider actual deployed mining hardware, not idealized protocol specs.

It demonstrates conservative evolution. Rather than redesigning the mining protocol, extend the existing system incrementally.

And it preserves optionality. By reducing nTime rolling, keep that field available for potential future consensus rules.

Most users will never notice this change. But it prevents subtle problems (timestamp drift, difficulty adjustment bias) and smooths the operation of the mining industry that secures the network.

The proposal is currently in review as GitHub PR #2116, opened March 5, 2026. It has received initial support from Bitcoin Core contributors, with Antoine Poinsot confirming the math and Mark Erhardt providing editorial review.

Sources

Sources: BIP Proposal PR #2116, Mailing List Discussion, Antoine Poinsot Response, BIP 320, Stratum v2 nTime Rolling Discussion, BIP 54 (Consensus Cleanup), Bitcoin Block Header Specification, AsicBoost Explanation. Status as of March 6, 2026.