BIP Draft: 24 nVersion bits for general purpose use

[TheBlueMatt]

No description provided.

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

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