This week I started making more involved changes to the stratum v2 repo to set up the necessary message passing infrastructure. Unsurprisingly, this is more time consuming than the work I have done in previous weeks. keyset_id message passing is not quite working yet so I did not complete any major milestones this week.
My strategy this far has been to generate blinded secrets at the appropriate place in the code using fake keyset data. In practice, the pool/mint will need to generate the keyset and transmit the keyset_id to the proxy/wallet before it can generate valid ecash tokens. I created two new message structs: SetupConnectionMint and SetupConnectionSuccessMint to carry this data.
I have my doubts as to whether this is the right approach but by pursuing this strategy I expect to learn a lot about the stratum v2 design and what this means in terms of engineering trade-offs. I would like to spend some more time understanding how stratum extensions are built but I think I can punt on this for now. The end result will most likely be an extension rather than a fork but in my engineering career I have found it very useful to consider the first implementation of any system as a practice round. When trying to do something new and hard you always end up rewriting it anyway, so by embracing epehemerality early on you can focus more on discovering the right requirements and abstractions for your needs rather than the ideal design.
I previously found that modifying the SetupConnection struct directly creates incompatibilities with bitcoind. Perhaps creating new messages can avoid this problem but it requires a lot of boilerplate code. In the process of building out the new message infrastructure I was surprised to find out that the jd client serves as a passthrough layer to establish a connection between the proxy and pool. I definitely should study the stratum protocol to better understand the topology of the various services.
I added keyset_id as a parameter of the JobDeclaratorClient, DownstreamMiningNode, and Upstream structs to store this state and pass it on when needed. This work on the upstream struct is still incomplete. For now, I have hard coded keyset ID to 0. I can see this in the logs so I know that the messages are working even if the value they are intended to carry isn't being transmitted fully.
Once I can pass the pool-generated keyset ID to the proxy I will need to build infrastructure to transmit the blinded messages to the pool, the pool will need to sign each share and then transmit the signatures back to the proxy for storage.
I have some personal travel plans coming up so I will spend next week putting together a Hashpool presentation for btc++ Berlin. There is a nostr hackathon before the conference so I might take some time to look into a nostr project. I suspect that storing your ehash on a nostr relay will be a critical usability feature. Maybe I can get a head start by meeting up with some nostr hackers in Berlin. Another idea is a nostr-powered ehash exchange.
I wrote a mini brain dump with an eye towards auditor requirements in a comment on this Sv2 auditor role issue. This is a good preview of the talk I plan to give. I will convert it to a presentation format, add visuals, explain what problems it solves, and add future development ideas.