feat: Stratum v2 Mining Protocol support

[average-gary]

Background

Following up on the discussion in #37 — I've put together a plan and started working toward adding native SV2 Mining Protocol support for downstream miners.

stratum-core vs legacy SRI crates

The concerns raised in #37 about technical debt and tight coupling in the *_sv2 crates are well-taken. Since that discussion, the stratum-mining org published stratum-core (v0.2.0), a ground-up refactor that consolidates the protocol primitives into a single crate with cleaner APIs — Responder for Noise handshake, StandardChannel/ExtendedChannel with built-in validate_share(), and all Mining Protocol message types. This plan uses stratum-core rather than the legacy individual crates.

Design

Dual-protocol: SV1 continues on port 3333, SV2 listens on port 3334. Both feed validated shares into the existing Emission pipeline — PPLNS accounting, block submission, and metrics work unchanged downstream.

Scope: Pool-side Mining Protocol only. No Job Declaration Protocol, no Template Distribution Protocol. The pool continues to build block templates via getblocktemplate + ZMQ.

Integration seam: SV2-validated shares produce the same Emission struct sent through the existing emissions_tx channel. Everything downstream is protocol-agnostic.

User identity: SetupConnection.user_identity enforces a Bitcoin address, same convention as SV1's mining.authorize.

Phases

Phase	Summary
0 — Foundation	Add stratum-core dependency, SV2 config section
1 — Connections	Noise handshake, SetupConnection handler, connection registry
2 — Channels	Standard channels, Extended channels, vardiff lifecycle
3 — Jobs	GBT→SV2 template bridge, job distribution, SetNewPrevHash
4 — Shares	SubmitSharesStandard/Extended, Emission bridge
5 — Wiring	main.rs integration, Docker/packaging
6 — Testing	Unit, integration, interop tests
7 — Metrics	Prometheus counters, Grafana dashboards

Detailed issue breakdowns and task tracking: Project Board

Approach

Developing on forks of both hydrapool and p2poolv2. The SV2 code lives as a new stratum_sv2/ module in p2poolv2_lib alongside the existing stratum/ module, with minimal changes to hydrapool itself (config + wiring in main.rs). Intent is to contribute upstream as PRs.

Open to feedback on the design or phasing.

[rkuester]

+1 for Sv2 in Hydrapool. We'll be working work towards landing Sv2 in Mujina too.

[pool2win]

This is so awesome! Thanks Gary for taking charge here. You know SV2 well, so it'll be great to have you build this out. The level of detail on your project is awesome too.

It is good to know the refactor is ready and stratum-core has been shipped. I'll take this opportunity to look at the relevant crates from there.

Which stratum-core crates will we need to import here? I saw in average-gary#2 that we import the entire stratum-core. Curious if we can selectively import from there?

The reason is to not build all dependencies of all the other crates that we don't use. This will also make the vulnerabilities checker flag all dependencies of all the crates that we don't even use. The con of direct imports is that we have to make sure the crates we do import from stratum-core will need to have compatible versions - I think we can manage that. What do you think?

Out of curiosity, which stratum-core crates do we need? I am just guessing a list here, so please be patient with my lack of awareness on the new crates structure.

• noise_sv2
• parsers_sv2?
• framing_sv2?
• mining_sv2?
• stratum_translation?

Also, you can leave the Prom/Grafan work out of the project. We need to do a re-write of the approach we took last year. I want to switch to open telemetrics and improve logging to Grafana too. The next telehash is in May. So I was punting that work till late March, early April.