BIP323: 24 nVersion bits for general purpose use #2116

TheBlueMatt commented at 11:50 AM on March 5, 2026: contributor

Mail list discussion: https://groups.google.com/g/bitcoindev/c/fCfbi8hy-AE/m/g85UXI4qAAAJ

in bip-XXXX.mediawiki:4 in e1ac2e7ab1

   0 | @@ -0,0 +1,43 @@
   1 | +<pre>
   2 | +  BIP: ?
   3 | +  Title: 24 nVersion bits for general purpose use
   4 | +  Author: Matt Corallo <bips@bluematt.me>

murchandamus commented at 6:02 PM on March 5, 2026:

  Authors: Matt Corallo <bips@bluematt.me>

in bip-XXXX.mediawiki:7 in e1ac2e7ab1

   0 | @@ -0,0 +1,43 @@
   1 | +<pre>
   2 | +  BIP: ?
   3 | +  Title: 24 nVersion bits for general purpose use
   4 | +  Author: Matt Corallo <bips@bluematt.me>
   5 | +  Status: Draft
   6 | +  Type: Specification
   7 | +  Created: 2026-02-26

murchandamus commented at 6:03 PM on March 5, 2026:

  Assigned: ?

in bip-XXXX.mediawiki:27 in e1ac2e7ab1

  22 | +
  23 | +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.
  24 | +
  25 | +==Rationale==
  26 | +
  27 | +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, and as been apparently adopted in some miners by using extra space in nTime as extra nonce space. Doing so in nVersion instead is preferable to using nTime.

murchandamus commented at 6:05 PM on March 5, 2026:

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. Doing so in nVersion instead is preferable to using nTime.

Also, for legibility of review comments, it would be preferable if you limited the length of the lines in the document.

in bip-XXXX.mediawiki:9 in e1ac2e7ab1

   0 | @@ -0,0 +1,43 @@
   1 | +<pre>
   2 | +  BIP: ?
   3 | +  Title: 24 nVersion bits for general purpose use
   4 | +  Author: Matt Corallo <bips@bluematt.me>
   5 | +  Status: Draft
   6 | +  Type: Specification
   7 | +  Created: 2026-02-26
   8 | +  License: BSD-3-Clause
   9 | +           CC0-1.0

murchandamus commented at 6:09 PM on March 5, 2026:

Since BIP3 deployed, we are using License Expressions for the License header values: https://github.com/bitcoin/bips/blob/master/bip-0003.md#specification-1

  License: BSD-3-Clause OR CC0-1.0

in bip-XXXX.mediawiki:39 in e1ac2e7ab1

  34 | +
  35 | +==Acknowledgements==
  36 | +
  37 | +Timo Hanke and Sergio Lerner for originally proposing 15-bit extra nNonce2. Btc Drak for writing BIP 320.
  38 | +
  39 | +==Changelog==

murchandamus commented at 6:11 PM on March 5, 2026:

Nit: It would be preferable to only add this section when it has content.

in bip-XXXX.mediawiki:10 in e1ac2e7ab1 outdated

   5 | +  Status: Draft
   6 | +  Type: Specification
   7 | +  Created: 2026-02-26
   8 | +  License: BSD-3-Clause
   9 | +           CC0-1.0
  10 | +  Replaces: 320

murchandamus commented at 6:14 PM on March 5, 2026:

I saw that this was discussed on the mailing list. Please add a Discussion header:

  Discussion: 2026-02-26: https://gnusha.org/pi/bitcoindev/6fa0cb45-37d6-4b41-9ff8-03730fd96d6e@mattcorallo.com/
  Replaces: 320

Please also add the corresponding Proposed-Replacement header to BIP 320.

murchandamus added the label New BIP on Mar 5, 2026

murchandamus added the label PR Author action required on Mar 5, 2026

TheBlueMatt commented at 8:07 PM on April 6, 2026: contributor

Addressed feedback.

TheBlueMatt force-pushed on Apr 6, 2026

murchandamus removed the label PR Author action required on Apr 6, 2026

in bip-XXXX.mediawiki:48 in c2f8667237

  43 | +==Backwards Compatibility==
  44 | +
  45 | +Non-upgraded nodes will interpret the reserved bits of this proposal as signals for soft forks, and
  46 | +may additionally activate the warning system for unknown soft forks.
  47 | +
  48 | +At the time of writing no known soft forks are pending using any of 24 bits reserved in this BIP,

murchandamus commented at 8:27 PM on April 6, 2026:

I saw AJ point out that there was a CTV deployment attempt that uses bit 5. I don’t think knowledge of that is widespread, but that should probably be addressed in the backwards compatibility section here.

darosior commented at 9:06 PM on April 20, 2026:

I don't think it makes sense to include a troll deployment in the backwards compatibility section of a serious BIP. As far as i know the activation parameters have not even been specified in a BIP in the first place.

TheBlueMatt commented at 11:17 PM on April 20, 2026:

Still, the wording as it was phrased was at least technically inaccurate. I updated the phrasing to say that no soft forks "which are being actively signaled for" are using these bits. Which I believe is true, the CTV deployment attempt is not being signaled for.

murchandamus commented at 8:52 PM on April 6, 2026: member

Concept ACK

Just got that one outstanding comment that should be incorporated.

murchandamus renamed this:
~~Add a BIP to define 24 bits of nVersion as nonce space not 16~~
BIP Draft: 24 nVersion bits for general purpose use
on Apr 6, 2026

plebhash commented at 3:30 PM on April 16, 2026: none

ACK from Sv2 contributor here

Sv2 introduces the notion of Header-only Mining (HOM) via Standard Channels, which freezes the merkle_root (no extranonce rolling inside the coinbase tx scriptSig), and leaves search space expansion to nVersion bits

HOM incurs in a few benefits for mining operations, namely:

pushing merkle_path+coinbase_tx_prefix+extranonce+coinbase_tx_suffix complexity to mining servers and proxies, away from mining devices
smaller wire bandwidth consumption due to:
- absence of merkle_path+coinbase_tx_prefix+coinbase_tx_suffix on NewMiningJob message (when compared to NewExtendedMiningJob)
- absence of extranonce on SubmitSharesStandard message (when compared to SubmitSharesExtended)
lighter share validation: validators can check shares against a precomputed job merkle_root instead of rebuilding it from merkle_path+coinbase_tx_prefix+extranonce+coinbase_tx_suffix for every share

in other words with HOM:

we're trading zillions distributed for few centralized merkle_root computations (where they actually matter)
we're trading notify+submit wire messages for lighter alternatives

and these can become meaningful optimizations when applied at scale.

the main challenge however, is the fact that currently, HOM is limited to a 280 TH/s ceiling (assuming nTime is only increased after 1s has elapsed, and not "rolled" into the future):

2^(NONCE_BITS + BIP320_VERSION_ROLLING_BITS) = 2^(32 + 16) = ~280Th

and the mining industry is already surpassing this limit on state-of-the-art devices

that would relegate Sv2 Standard Channels to a second tier, throwing away the potential optimizations that HOM can bring when applied at scale on mining farms

therefore, lifting the number of rollabe nVersion bits is a highly desirable change from the perspective of the optimizations that Sv2 can bring to Bitcoin Mining

rkuester commented at 4:23 PM on April 16, 2026: none

Concept ACK from the Mujina mining firmware maintainer, for the reasons @plebhash mentions above as well as reasons outlined in the draft.

murchandamus added the label Needs number assignment on Apr 20, 2026

murchandamus commented at 11:27 PM on April 20, 2026: member

Thanks for the update, LGTM

Add a BIP to define 24 bits of nVersion as nonce space not 16 70253d21d0

TheBlueMatt force-pushed on Apr 21, 2026

TheBlueMatt commented at 12:41 PM on April 21, 2026: contributor

Squashed without further changes.

in bip-XXXX.mediawiki:9 in 70253d21d0

   0 | @@ -0,0 +1,58 @@
   1 | +<pre>
   2 | +  BIP: ?
   3 | +  Title: 24 nVersion bits for general purpose use
   4 | +  Authors: Matt Corallo <bips@bluematt.me>
   5 | +  Status: Draft
   6 | +  Type: Specification
   7 | +  Assigned: ?
   8 | +  License: BSD-3-Clause OR CC0-1.0
   9 | +  Discussion: 2026-02-26: https://gnusha.org/pi/bitcoindev/6fa0cb45-37d6-4b41-9ff8-03730fd96d6e@mattcorallo.com/

jonatack commented at 4:45 PM on April 21, 2026:

The following links directly to the top post of the full discussion.

  Discussion: 2026-02-26: https://groups.google.com/g/bitcoindev/c/fCfbi8hy-AE/m/g85UXI4qAAAJ

in bip-XXXX.mediawiki:39 in 70253d21d0

  34 | +
  35 | +Headers-only mining avoids mining devices (either ASICs or the firmware) from having to concern
  36 | +themselves with the vast space of consensus logic (handling transactions, merkle trees, etc). It is
  37 | +widely deployed in ASICs, but requires a substantial number of jobs fed across an entire device,
  38 | +keeping the ASIC controller busy. Providing additional nonce space for the ASICs to roll without
  39 | +needing fresh work from the controller may simplify ASIC design somewhat, and as been apparently

jonatack commented at 4:48 PM on April 21, 2026:

needing fresh work from the controller may simplify ASIC design somewhat, and has been apparently

(a source footnote for "apparently adopted in some miners" may be helpful here)

in bip-XXXX.mediawiki:48 in 70253d21d0

  43 | +==Backwards Compatibility==
  44 | +
  45 | +Non-upgraded nodes will interpret the reserved bits of this proposal as signals for soft forks, and
  46 | +may additionally activate the warning system for unknown soft forks.
  47 | +
  48 | +At the time of writing no soft forks which are being actively signaled for are using any of the 24

jonatack commented at 4:49 PM on April 21, 2026:

At the time of writing no soft forks that are being actively signaled for are using any of the 24

murchandamus removed the label Needs number assignment on Apr 22, 2026

murchandamus renamed this:
~~BIP Draft: 24 nVersion bits for general purpose use~~
BIP323: 24 nVersion bits for general purpose use
on Apr 22, 2026

murchandamus commented at 7:59 PM on April 22, 2026: member

Let’s call this BIP323! You know the drill: could you please rename the file, update the preamble, add a README table entry, and put the number in the Proposed-Replacement header of BIP320?