592 sats \ 3 replies \ @davidw 22 Mar \ on: AMA - Stratum V2 SRI team, yesterday we released an important update 1.0.0! AMA
What didn’t get added to the release that you wish could have, had you had more time & resources?
I’m sure you had to cut something ✂️ always love to know more about how decisions are made by builders
write
preview
this territory is moderated
263 sats \ 2 replies \ @plebhash 22 Mar
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).
reply
320 sats \ 1 reply \ @davidw 22 Mar
And what would that potentially unlock in your mind? Allowing you to write more custom rules around which pool to use and when?
reply
899 sats \ 0 replies \ @plebhash 22 Mar
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:

leveraging low-level APIs
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:
  • threading model
  • error handling
  • socket handling
  • coinbase management (very simplistic)
  • share accounting (basically non-existent)
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).

leveraging high-level APIs
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.
reply