StratumV2 support

[jayrmotta]

I've been playing and testing SV2 for a while now so naturally #11 caught my attention, but it seems abandoned. So I decided to build a new implementation as an experiment and to drive my learning of SV2's protocol.

The branch linked above is not something I would currently propose as it was mostly designed and implemented by my AI agents. However, I have iterated on it quite a bit, enough to have it working stable pointing to the SRI pool.

Architecture

The entry point would be through URL parsing stratum2+tcp in our daemon.

A new source would be introduced to job_source and also a new module stratum_v2, these would be the foundation to handle connectivity, cryptography, marshalling, message exchange/routing, and fit naturally along other sources like job_source/stratum_v1 and the analogous stratum_v1 module.

At lower levels we will need to introduce support for fixed merkle root as we currently only support computed merkle root, that is needed for SV2's HOM (header-only mining) which is the usual behavior for end devices. For extranonce search space slicing SV2's spec describes separate architectural components (i.e. mining proxy).

Request for comments

I'm looking for comments on what should Mujina's SV2 support look like. My idea now that I feel a little more comfortable with the protocol to refactor the whole solution into simpler modules, structs, functions, with better placed/named symbols.

Soon as I get more confident with the design I will open a draft PR for reviews, for now I would just like to gather some guidance from the community, especially from @plebhash and @rkuester on pitfalls to avoid, general principles, and so on.

[plebhash]

SV2's HOM (header-only mining) which is the usual behavior for end devices. For extranonce search space slicing SV2's spec describes separate architectural components (i.e. mining proxy).

I think this is aligned with the vision of the original Sv2 spec draft. However, HOM is currently limited to 280 TH/s. There are efforts to expand the number of rollable version bits (as currently established by BIP320):

• 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 (not sure what the hard ceiling will be, but I think it's safe to assume it will be orders of magnitude bigger).

But it's hard to say if/when that will happen, and I assume Mujina could be used to drive Mining Devices above 280 TH/s in the near future (before rollable version bits are expanded).

Therefore, I wouldn't necessarily restrict Sv2 support in Mujina to Standard Channels only, and keep Extended Channels a viable implementation path.

At lower levels we will need to introduce support for fixed merkle root as we currently only support computed merkle root, that is needed for SV2's HOM (header-only mining)

Given that Standard/HOM will require deeper changes on Mujina, perhaps it might make sense to start with Extended Channels instead?

[plebhash]

there's been similar questions here

here's the reasons for supporting Sv2 Standard Channels on the client level:

• pushing merkle_path+coinbase_tx_prefix+extranonce+coinbase_tx_suffix complexity upstream
• 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:

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

[plebhash]

another way to look at it is from a historical perspective:

as Moore's law expanded hashrate, people realized they could "roll" merkle_root circa 2011:

• CBlock.GetSigOpCount counts vtx[0].vin[0] bitcoin/bitcoin#596
• https://bitcointalk.org/index.php?topic=7219.0
• https://bitcointalk.org/index.php?topic=27599.0

this practice got formalized into GBT BIP-23 circa 2012:

• https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki

only much later (circa 2018) people realized they could roll nVersion, which got formalized into BIP310+BIP320:

• https://github.com/bitcoin/bips/blob/master/bip-0310.mediawiki
• https://github.com/bitcoin/bips/blob/master/bip-0320.mediawiki

so from a historical perspective, IMO the "industry already does it this way, why pivot away?" argument loses its strength... at least from the mindset of "Sv2 is an opportunity to do mining the right way"

just because merkle_root rolling "ossified" first into ASIC+CB+FW design, that doesn't mean it's the most efficient way to do things at scale

in fact, I'd argue that if/when the 280 TH/s HOM ceiling is lifted via expansion of rollable nVersion bits, the way that @jayrmotta originally framed things on this Discussion would/should be the norm:

mining devices should prefer Standard Channels, leaving Extended Channels for proxies to do search space allocation

at scale, these guidelines should incur in optimized operations

[plebhash]

with that said, what I said earlier still holds:

if Extended Channels are a lower hanging fruit for Sv2 Mujina in the short term, you guys should definitely start there!

[rkuester]

Okay, those points make sense. Thank you for spelling them out. I'm sold on the idea Standard Channels should be the default—especially once rollable version is 24-bits wide.

As a client author, my primary concern was that if there are two channel types, the client needs logic to choose between them, and or provide configuration for the user, educate them on how to make the decision, etc. Without a compelling reason to offer both types, I was inclined to simplify and provide only the more capable type. Furthermore, this seemed like the most straightforward way to handle 280 TH/s issue.

Considering the motivation you've provided above, I drop my objections to implementing both. It won't be difficult to support both channel types; I designed our types with that in mind from the outset. However, I didn't fully implement them once I considered the aforementioned concerns. Dealing with the 280 TH/s limit in the short term will be the most annoying part.

I fully endorse this 24-bit wide rolling version effort! I'll add a comment to that BIP draft.

[jayrmotta]

I'm sold on the idea Standard Channels should be the default—especially once rollable version is 24-bits wide.

The support for additional bits in nVersion is on the way with bitcoin-core v32: bitcoin/bitcoin#34779

Since the new ceiling would be 72PH/s there is an argument to change our SV2 implementation and support standard channels instead.

Thoughts @rkuester ?

[plebhash]

please note that SubmitShares.Success usually ACKs shares in batches

while SubmitShares.Error nACKs individual shares

not sure if this was already clear to @jayrmotta, but since it's not explicitly shown in the diagram above I feel it might be worth pointing out

[jayrmotta]

That's a good shout as it also touches on how accounting is done client side, the current SV1 client accounts on submission while my SV2 support branch accounts batches when the shares are ACKed.

I don't see why SV1 couldn't or shouldn't do the same, so perhaps the final solution will also change how we do client side accounting regardless of protocol.

[rkuester]

Makes sense. The current SV1 client definitely has room for improvement. Might be helpful to represent and or present this as a rejected count alongside a submitted count.

[rkuester]

Yes, @jayrmotta. You've got the right idea. SV2 should naturally fit alongside SV1 as yet another type of job_source. Ideally, the job_source interface as it currently stands is sufficient, and Mujina will function seamlessly, oblivious to the origin of the jobs. Of course, we can extend the job_source interface if there are additional requirements. I attempted to anticipate the needs of SV2 when I created the abstraction.

[rkuester]

Hey, @jayrmotta. I believe you did find a subtle bug here in the current implementation, though I'm not sure this is the right fix.
Would you mind creating an issue for it and perhaps trying to patch it?

[rkuester]

One last comment, on a general principle. It would be good to get into the habit of chunking changes of this size into a series of small atomic commits. See the guideline in CONTRIBUTING.md, "Atomic Commits". This would make it easier to review, among other things.

For example, the single commit on this branch could be turned into a series like:

• fix(bm13xx): unify nonce-side merkle root resolution on task_to_job_full (pre-existing latent bug)
• fix(bm13xx): drop duplicate chip nonce reports for the same block hash (pre-existing too, if true)
• feat(daemon): build Stratum user-agent from CARGO_PKG_VERSION
• feat(job_source): add SharesAccepted event for ack-driven share counting
• fix(scheduler): drop stale TaskEntries on AssignMode::Update
• feat(scheduler): support header-only jobs with fixed merkle roots
• feat(config): add Stratum V2 endpoint, identity, and authority pubkey config
• feat(stratum_v2): add framed client with Noise handshake (the whole new stratum_v2 module, on its own)
• feat(job_source): add Stratum V2 job source
• feat(daemon): dispatch Stratum V1 vs V2 from pool URL

See the commits of PR #24 for another, real-life example.

I understand that the commit you linked is just a prototype, and you didn't intend it to be a real PR. However, I wanted to bring this to your attention, especially while you're working on the real PR.

[plebhash]

tip: while it is possible to integrate low-level crates such as codec_sv2 + noise_sv2, I would recommend looking into stratum-apps::network_helpers

this module was written to provide high-level abstractions to establish encrypted connections between two Sv2 nodes

[rkuester]

Jayr's third SV2 implementation attempt is up for review: #65