I find it hard to estimate a timeline. My imagination around this happens more in terms of sequence of events.

As soon as pools start adopting SV2, or even new pools show up (e.g.: Demand), we would expect more hashrate being produced via SV2.

If we start to notice a trend where SV1 hashrate starts migrating towards SV2 (even if via translator proxies, from legacy SV1 ASICs), that will be a clear pressure for legacy pools to start moving towards adoption, and everything should be a trickle down effect from there.

SRI stands for Stratum Reference Implementation, and is meant to act as the building blocks for the Bitcoin mining infrastructure.

Now imagine someone wants to write a sv2-enabled pool based on SRI. There are infinite different directions they could go, which I will try to summarize in two main ones:

Right now, SRI has implementation for roles crates, which do include a "demo" pool. But this is just a dummy project which only exists for the purpose of showcasing how to wire the low-level libraries together (e.g.: crates under protocols, commons and utils). This pool implementation is somewhat opinionated in regards to multiple factors, namely:

If someone wants to leverage the low-level libs while writing a production-ready pool from scratch under a different architecture, that is already doable. We believe these low-level crate libs are relatively mature, which is why they are all set as v1.0.0.

This is also likely a path to most pools that already have some codebase, but only wish to integrate SV2 in a modular way. While SRI is a Rust codebase, it provides FFIs to enable integration with other programing languages (e.g.: C, C++, Python).

Putting low-level libraries together implies heavy-lifting. That could be time-consuming and somewhat prohibitive to small teams. That is why it is also desirable that SRI provides high-level libraries with building blocks for roles implementations.

That way, if some small team wishes to implement a pool in a specific way, SRI would already provide some building blocks for that. These building blocks would be opinionated with regards to threading model, error handling, socket handling and any other general aspects of the software. The pool team could then implement their own opinionated strategiesfor coinbase management and share accounting, without necessarilty spending thousands of man-hours on wiring together the low-level APIs.

I still want to make more improvements to the roles implementations.

Right now they are just PoCs that demo how the low-level APIs can be used. But I want to eventually put them into a shape where they could be used as high-level API for custom implementations of roles (e.g.: pools, proxies and JDs).

Just because these pools dominate hashrate today, it doesn't mean they will do so forever.

As soon as market dynamics change, they could lose hashrate to other pools that provide more transparency.

In fact, block template is not the only issue with centralization on the mining industry nowadays. There's still lots of improvements to be made with regards to transparency and decentralization around share accounting and payout mechanisms. As soon as pools start implementing those (regardless of how small they are initially), other pools will be forced to follow.

SV2 doesn't really bring any innovation around these aspects however. That is still up to the pools to implement those.

I take it as part of my mission to democratize bitcoin mining, so in my ideal world it shouldn't be.

Unfortunately, it does require some fundamental knowledge and some research is advised. I do believe there is a sweet spot on how much technical knowledge someone needs, but this sweet spot is still to be found via collective learning and experimentation.

Pleb miners are fundamentally different to industrial miners, and there shouldn't be expectations to achieve the same level of profitability.

For example, the price of residencial energy on most places in the world today make it relatively hard to remain profitable.

That doesn't mean people shouldn't do it, nevertheless. It is still possible for a pleb miner to get small ASIC devices and do solo-mining with it, in a "lottery" style. That is mostly an ideologically driven activity, which could be labeled as "economically irrational". But hey, if you want to help decentralize bitcoin mining and you don't mind having the equivalent of an extra light-bulb on your electricity bill, why not?

Projects like the BitAxe are really helpful for this.

SRI has a translator proxy which takes SV1 hashrate and sends it to SV2 pools.

That should allow for older devices (like the S9) to still be included in the game.

A translator proxy could be deployed by the hosted service or by the pleb miner themselves.

If the hosted service deploys the translator, the main innovation will be the ability for Template negotiation with the pleb miners.

If the pleb miner deploys the translator themselves, other improvements should come with it, namely:

it's actually a big playlist with multiple videos, but this specific one will introduce SV1 on a historical context and highlight why SV2 was necessary

I've been working on FOSS for about 5y now. I was on the shitcoin world until recently, but now I'm a grantee with Spiral and my experience towards a grant consisted of several factors:

These items above helped me get context on the team activity. It is important not only to be willing to help, but also to understand what kind of help is needed, and what are the current priorities.

Eventually I saw SteveLee/moneyball mention on SV2 Discord that the SRI team needed experienced Rust devs to join the team and Spiral was willing to give out more grants. So I reached out to him and started talking. Some key points of our interaction were me sharing my CV and him telling me to join some calls with @pavlenex and @Fi3 to agree on what the project's roadmap needed more hands and how I could commit myself to helping it.

some resources on SV1 vs SV2 differences:

it means everyone can/should give it a try and help the SRI team understand how the community intends to adopt it, so we can fix bugs and make adaptations to the APIs