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.

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

[TheBlueMatt]

Addressed feedback.

[murchandamus]

Gave this another read. LGTM. @TheBlueMatt: Unless you’re waiting for something or have more planned work, I propose that this can be published later this week. WDYT?

[TheBlueMatt]

I see no reason to hold this up on anything else. I believe @darosior was planning to "update" Bitcoin Core (which AFAIU just means changing some logging and RPC warnings).

[ajtowns]

I believe @darosior was planning to "update" Bitcoin Core

This is bitcoin/bitcoin#34779