lifting the hashrate ceiling of Standard Channel HOM

[plebhash]

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

but happily there are efforts to expand the number of rollable version bits (as currently established by BIP320 + BIP310):

• BIP323: 24 nVersion bits for general purpose use bitcoin/bips#2116
• BIP 323: reserve version bits 5-28 as extra nonce space bitcoin/bitcoin#34779

that will allow HOM to be used on devices above 280 TH/s

[plebhash]

BIP proposal was assigned number 323: bitcoin/bips#2116 (comment)

[plebhash]

BIP323 merged:

• as a BIP: BIP323: 24 nVersion bits for general purpose use bitcoin/bips#2116
• on Bitcoin Core (set to land on v32.x): BIP 323: reserve version bits 5-28 as extra nonce space bitcoin/bitcoin#34779

[GitGab19]

That's a great news, thanks for updating us about it!

What would our next steps be? Should we simply update the specs paragraph which mentions the 280th/s limit with Standard Channels?

[plebhash]

updating specs would be the first step, yes

but we should also check whether SRI needs to be adapted

my intuition says yes, but I'd have to think more deeply before giving a more confident answer

[plebhash]

• tracker for spec changes: BIP323 adaptations #199
• tracker for stratum repo: BIP323 adaptations stratum#2194
• tracker for sv2-apps repo (only translator_sv2 needs changes): tProxy: BIP323 adaptations sv2-apps#559