Update after 3 days of the stratum v2 experimental code. I'm very pleased with the performance of the protocol and plan to make it a permanent feature of solo ckpool. After a few more pool updates to tighten sv2 conformance and performance upgrades for anticipated heavy usage in future, everything is still running smoothly. At this point I'll let it run till next week unchanged, and if no further improvements come to mind and it remains stable I'll deploy it on all the solo pools as dual instance SV1/SV2 endpoints from all locations. This should be a transparent process to miners. Regular stratum mining should remain unaffected, and there should be no discernible downtime to miners.

Update after the first day of experimental stratum v2 support. The sv2 pool is currently sitting around 300TH from 6 users/10 workers (including my own hashrate) and all seems to be working fine. For those configuring SV2 mining, the mining endpoint is: and the job declaration endpoint is What's currently missing is a high diff port for rentals (@Braiins already offer native SV2 rental hashrate) and I will deploy that in the near future. Assuming SV2 is here to stay, these URLs will likely remain and propagate across all the pools. Stratum V1 mining is here to stay indefinitely and will be unaffected - they will both be running from the same ckpool code. The ckpool code itself will eventually be made public once it reaches a stable state. In addition I'm working on extending ckpool in proxy mode aka ckproxy to be a stratum v1 to v2 proxy. This will also follow the public release of ckpool with v2. I'm also aware that some people took my initial post to be very negative regarding stratum v2, but that was not my intent at all - I was trying to describe the compromise nuances on a technical level. So I'll try to clarify: - Native stratum v2 end to end is a positive on all fronts. My benchmarking v1 vs v2 on ckpool specifically shows latency is basically identical. The advantages are security, privacy, and a trivial bandwidth decrease. - Stratum v1 to stratum v2 via a proxy I can now say after benchmarking it has no significant latency increase so can still obtain many of the benefits of Sv2 but is currently not that straight forward to set up. - Stratum v2 with job declaration (mine your own templates/transactions) is a decentralisation aid that comes with a modest latency hit tradeoff. It is significantly more complex to set up than basic v1 to v2 proxying. It should become the defacto standard for regular pooled mining, but _currently_ offers no advantage in lottery aka solo pools. Hopefully highlighting this will help the devs focus their attention to minimise or even abolish the tradeoff in time. On a technical level, I think pools should be allowed to send work in JD mode on an updatedtip and simply allow the client to decide whether to use that work or not until it updates its own tip. It will provide the best of all worlds. Leaving the decision to the client takes away the concern that a pool will override the client's work. Mine on!