BIP 323: 24 nVersion bits for general purpose use
In plain English: Reserves 24 bits of the block header's version field as extra space miners can vary while searching for a valid block. This lets fast mining hardware keep working on just the block header without changing the timestamp more often than once per second.
- Status
- Draft
- Type
- Specification
- Authors
- Matt Corallo
- Assigned
- Last changed
- Replaces
- BIP 320
- Topics
- Payments
- Source
- bip-0323.mediawiki on GitHub · Markdown
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 https://github.com/stratum-mining/sv2-spec/discussions/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, https://github.com/bitcoin/bitcoin/pull/34779#issuecomment-4026385773 and https://github.com/bitaxeorg/ESP-Miner/pull/1553#issuecomment-3936223444
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.