BIPs bitcoin improvement proposals

24 nVersion bits for general purpose use

  BIP: 323 source
  Title: 24 nVersion bits for general purpose use
  Authors: Matt Corallo <bips@bluematt.me>
  Status: Draft
  Type: Specification
  Assigned: 2026-04-22
  License: BSD-3-Clause OR CC0-1.0
  Discussion: 2026-02-26: https://groups.google.com/g/bitcoindev/c/fCfbi8hy-AE/m/g85UXI4qAAAJ
  Replaces: 320

Table of Contents

Abstract

24 bits are reserved in the nVersion field as extra nonce space for miners, providing for additional hashrate with header-only mining without relying on rolling nTime more often than once per second.

Motivation

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 (see stratum-mining/sv2-spec#187). Given there's limited utility in 16 bits of nVersion space for signaling, instead here we offer 24 bits of nVersion space as extra nonce space.

Specification

24 bits from the block header nVersion field, starting from 5 and ending at 28 inclusive (0x1fffffe0), are reserved for nonce use and removed from BIP8 and BIP9 specifications. A mask of 0xe000001f should be applied to nVersion bits so bits 5-28 inclusive will be ignored for soft-fork signalling and unknown soft-fork warnings.

Rationale

Headers-only mining avoids mining devices (either ASICs or the firmware) from having to concern themselves 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, and has been apparently adopted in some miners by using extra space in nTime as extra nonce space[1]. Doing so in nVersion instead is preferable to using nTime.

[1] See, eg, bitcoin/bitcoin#34779 (comment) and bitaxeorg/ESP-Miner#1553 (comment)

Backwards Compatibility

Non-upgraded nodes will interpret the reserved bits of this proposal as signals for soft forks, and may additionally activate the warning system for unknown soft forks.

At the time of writing no soft forks that are being actively signaled for are using any of the 24 bits reserved in this BIP. Future soft forks SHOULD NOT utilize those bits for activation signaling.

Acknowledgements

Timo Hanke and Sergio Lerner for originally proposing 15-bit extra nNonce2. Btc Drak for writing BIP 320.

Copyright

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.