BIP xxx: reserve version bits 5-28 as extra nonce space

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).

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.

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

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

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

versionbits: Limit live activation params and activation warnings per BIPXXX

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

37111cb4f6

qa: test we don't warn for ignored unknown version bits deployments

Co-Authored-by: Anthony Towns <aj@erisian.com.au>

7e20cf797f

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

Reviews