BIP 323: reserve version bits 5-28 as extra nonce space #34779

pull darosior wants to merge 4 commits into bitcoin:master from darosior:2602_more_version_bits_rolling changing 7 files +58 −8

darosior commented at 7:06 PM on March 9, 2026: member

This implements https://github.com/bitcoin/bips/pull/2116, which repurposes 24 version bits as extra nonce space for miners rather than soft fork deployment coordination. 24 bits allows a miner to perform up to 72 PH before needing a fresh job from its controller. The current 16 bits in use by miners only allow up to 280 TH, which apparently led some ASIC designers to start rolling the timestamp field on their beefier machines.

Mailing list discussion available here. A previous shot at this is #13972 (with a smaller extranonce space).

This change only affects the warning logic.
DrahtBot commented at 7:07 PM on March 9, 2026: contributor



The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34779.



Reviews

See the guideline for information on the review process.

Type Reviewers

ACK sedited, ajtowns, optout21, achow101

Concept ACK jonatack

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.
darosior force-pushed on Mar 9, 2026
DrahtBot added the label CI failed on Mar 9, 2026
darosior commented at 7:16 PM on March 9, 2026: member

cc @johnny9 since i'm linking to your comment as part of the rationale for this PR.
ajtowns commented at 7:17 PM on March 9, 2026: contributor

Would moderately prefer to leave regtest's TESTDUMMY out of the ordinary bounds. Can we make VERSIONBITS_NUM_BITS a chainparams setting instead, and leave it at 29 for regtest?
johnny9 commented at 7:50 PM on March 9, 2026: contributor

To add more context. The BZM2 that will roll up to 7 bits of ntime is a failed commercial product. It rolled ntime internally instead of version bits that are already standard use. All antminer chips use version properly. Someone can do the math on if that's enough.
darosior force-pushed on Mar 9, 2026
darosior commented at 8:17 PM on March 9, 2026: member

It's already too late for those commercially available miners that roll timestamps. But it does point out to a desire for more extranonce space from manufacturers, and hopefully rolling 24 version bits can become a viable alternative before more timestamp-rolling ASICs get shipped.
DrahtBot removed the label CI failed on Mar 9, 2026
ajtowns commented at 8:13 AM on March 10, 2026: contributor
Here's what I think this should be doing: https://github.com/ajtowns/bitcoin/commits/202603-bipxxx-versionbits/ (4 files, +34-5 instead of 10 files, +63-42).

It avoids changing consensus logic, and keeps versionbits itself supporting all 29 bits as per BIP9, and only restricts the warning bits logic and the non-TESTDUMMY deployments to the new BIPxxx 5 bit limit. That allows continuing to use bit 28 for TESTDUMMY to test the versionbits logic without having to worry about a real deployment conflicting with, and also leaves the unit and fuzz tests alone, as they're still testing the same behaviour, and likewise doesn't require changing any of the hardcoded functional test hashes.
```
> darosior: _aj_: why have the dummy deployment out of the bounds of the deployment we support?
> _aj_: darosior: avoids changing all the constants, and avoids using up a real deployment
>       slot for a test case
> darosior: downside is: we don't test deployment activation using a real deployment slot
```
With the logic here, all the deployment slots are "real" deployment slots; the only thing that's changed is the warning code, and our test suite will automatically error if we try to use a slot outside the new range for a real deployment.
```
> darosior: Also the constant `VERSIONBITS_NUM_BITS` would still have to change, so this would
>           only save updating the test constant in mining_basic.py and the hardcoded bit in
>           rpc_blockchain.py. Not clear to me it's worth it
```
That constant doesn't need to change.
plebhash commented at 10:31 PM on March 10, 2026: none
cross referencing:
- https://github.com/stratum-mining/sv2-spec/discussions/187
- https://github.com/stratum-mining/sv2-spec/discussions/193
darosior force-pushed on Mar 11, 2026
darosior commented at 5:27 PM on March 11, 2026: member

I think it's preferable to stop supporting deployment with version bits >= 5 altogether, if this space is to be used as an extranonce going forward. But i am not opposed to simply stop warning for those bits for now, and the smaller diff is attractive. If it makes sense, we can still go all the way at a later time.

I pushed @ajtowns' commit with some small adjustments. My former approach is available here for comparison.

That constant doesn't need to change.

Sure, but only because you introduce a new one that serves the same purpose and use it in all non-test code instead! I've modified your commit to instead update the constant and introduce the test-only constant in src/test/util instead.
darosior closed this on Mar 11, 2026
darosior force-pushed on Mar 11, 2026
darosior reopened this on Mar 11, 2026
ajtowns commented at 4:34 AM on April 24, 2026: contributor

This got assigned bip 323.
darosior force-pushed on Apr 24, 2026
darosior renamed this:
~~BIP xxx: reserve version bits 5-28 as extra nonce space~~
BIP 323: reserve version bits 5-28 as extra nonce space
on Apr 24, 2026
darosior commented at 2:19 PM on April 24, 2026: member

Updated PR and commit titles with assigned BIP number.
jonatack commented at 3:21 PM on April 24, 2026: member

Concept ACK, light review LGTM

Type	Reviewers
ACK	sedited, ajtowns, optout21, achow101
Concept ACK	jonatack

in src/versionbits.h:25 in f660dac9ab outdated

  21 | @@ -22,7 +22,7 @@ static const int32_t VERSIONBITS_TOP_BITS = 0x20000000UL;
  22 |  /** What bitmask determines whether versionbits is in use */
  23 |  static const int32_t VERSIONBITS_TOP_MASK = 0xE0000000UL;
  24 |  /** Total bits available for versionbits */
  25 | -static const int32_t VERSIONBITS_NUM_BITS = 29;
  26 | +static const int32_t VERSIONBITS_NUM_BITS = 5;

ajtowns commented at 3:13 PM on May 13, 2026:

Comment should reference BIP 323.

The comment above class VersionBitsCache could perhaps also be updated (we cache state for each deployment we currently implement, and warning state for each bip323 allowed bit)

darosior commented at 2:56 PM on May 20, 2026:

Done both.

in src/test/util/versionbits.h:10 in 39876f6c07
```
   5 | +#ifndef BITCOIN_TEST_UTIL_VERSIONBITS_H
   6 | +#define BITCOIN_TEST_UTIL_VERSIONBITS_H
   7 | +
   8 | +#include <versionbits.h>
   9 | +
  10 | +/** Total possible bits available for versionbits */
```
ajtowns commented at 5:46 PM on May 13, 2026:

Consider adding "per original BIP 9 specification" to the comment?

darosior commented at 2:53 PM on May 20, 2026:

I added "possible" to capture this, but expanding a bit doesn't hurt. Done.
ajtowns commented at 5:46 PM on May 13, 2026: contributor

ACK f660dac9ab457949acb90997ec07b5454fcba957

Should add a release note I think. Probably should also update doc/bips.md.
DrahtBot requested review from jonatack on May 13, 2026
darosior force-pushed on May 20, 2026
sedited added this to the milestone 32.0 on May 23, 2026
sedited approved
sedited commented at 9:17 PM on May 25, 2026: contributor

ACK 4af40a82b9d6f3da0e9a6523017563d2569700d0

Can you make it explicit in the first commit message and the PR description that this only has an effect on the warnings and that the test bits stay the same?
DrahtBot requested review from ajtowns on May 25, 2026

versionbits: Limit live activation params and activation warnings per BIP323

Test bits are conserved. This only has an effect on the warnings.

Co-Authored-By: Antoine Poinsot <mail@antoinep.com>

f802edf57c

qa: test we don't warn for ignored unknown version bits deployments
Co-Authored-by: Anthony Towns <aj@erisian.com.au>
1d5240574a
doc: release notes and bips doc update for #34779 94e3ac0b21
versionbits: update VersionBitsCache doc comment to match current behaviour
Co-Authored-by: Anthony Towns <aj@erisian.com.au>
107d4178d9

in test/functional/feature_versionbits_warning.py:22 in 465774c28b

  19 |  VB_PERIOD = 144           # versionbits period length for regtest
  20 |  VB_THRESHOLD = 108        # versionbits activation threshold for regtest
  21 |  VB_TOP_BITS = 0x20000000
  22 | -VB_UNKNOWN_BIT = 27       # Choose a bit unassigned to any deployment
  23 | +VB_UNKNOWN_BIT = 3        # Choose a bit unassigned to any deployment
  24 | +

darosior commented at 1:50 PM on June 1, 2026:

nit: this newline should go in the next commit.

darosior commented at 2:12 PM on June 1, 2026:

Done.

darosior force-pushed on Jun 1, 2026
darosior commented at 2:14 PM on June 1, 2026: member

Updated PR description and first commit message to state this only has an effect on warnings and that existing test bits are conserved.
sedited approved
sedited commented at 4:05 PM on June 1, 2026: contributor

Re-ACK 107d4178d9184f62c74084f5954cc36f3213434f
ajtowns commented at 5:25 PM on June 1, 2026: contributor

ACK 107d4178d9184f62c74084f5954cc36f3213434f
sedited requested review from stickies-v on Jun 1, 2026
sedited requested review from willcl-ark on Jun 1, 2026

in src/test/util/versionbits.h:8 in f802edf57c

   0 | @@ -0,0 +1,13 @@
   1 | +// Copyright (c) 2026-present The Bitcoin Core developers
   2 | +// Distributed under the MIT software license, see the accompanying
   3 | +// file COPYING or http://www.opensource.org/licenses/mit-license.php.
   4 | +
   5 | +#ifndef BITCOIN_TEST_UTIL_VERSIONBITS_H
   6 | +#define BITCOIN_TEST_UTIL_VERSIONBITS_H
   7 | +
   8 | +#include <versionbits.h>

optout21 commented at 8:17 AM on June 2, 2026:

f802edf versionbits: Limit live activation params and activation warnings per BIP323:

Nit: Is this include really needed here?

darosior commented at 7:21 PM on June 3, 2026:

Right, it's unnecessary

optout21 commented at 8:47 AM on June 2, 2026: contributor

ACK 107d4178d9184f62c74084f5954cc36f3213434f

Reviewed code. Double checked against the text of BIP 323. Checked codebase for any reference of BIP 323, BIP 320, BIP 9, 29. Ran unit tests locally. Left one nit comment.
achow101 commented at 6:27 PM on June 3, 2026: member

ACK 107d4178d9184f62c74084f5954cc36f3213434f
achow101 merged this on Jun 3, 2026
achow101 closed this on Jun 3, 2026
darosior deleted the branch on Jun 3, 2026