BIP323: 24 nVersion bits for general purpose use

[TheBlueMatt]

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

[TheBlueMatt]

Addressed feedback.

[murchandamus]

Concept ACK

Just got that one outstanding comment that should be incorporated.

[murchandamus]

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]

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]

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.

[plebhash]

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]

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

[murchandamus]

Thanks for the update, LGTM

[TheBlueMatt]

Squashed without further changes.

[jonatack]

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

Suggested change

	Discussion: 2026-02-26: https://gnusha.org/pi/bitcoindev/6fa0cb45-37d6-4b41-9ff8-03730fd96d6e@mattcorallo.com/
	Discussion: 2026-02-26: https://groups.google.com/g/bitcoindev/c/fCfbi8hy-AE/m/g85UXI4qAAAJ

[jonatack]

Suggested change

	needing fresh work from the controller may simplify ASIC design somewhat, and as been apparently
	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)

[jonatack]

Suggested change

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

[murchandamus]

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?