It's been a busy two months. The hashpool infrastructure is maturing nicely. I have gotten my development environment to a comfortable state, rolled out several critical upgrades, gained a few contributors, and landed a full time grant. Everything's coming up aces! 🂡

Contributing to the Infra

I put out a few messages on social media and participated as a mentor in the ATLBitLab mining themed hackathon. You can see my mentor presentation here. The hackathon didn't lead directly to any Hashpool contributions but somewhere along the way I attracted two contributors. This is an extremely exciting development because an open source project lives or dies on its ability to attract developers.

My boy MachuPikacchu built a mint api that allows the proxy service to query for cashu quote IDs by share hash. This is an essential component in retrieving ehash tokens from the mint. He also did some foundational work on the mint and wallet sqlite migration.

Chad OptOut21 is working to enable ehash redemptions. He (she? they? idk and that's awesome!) added regtest support and stood up a CLN role for the project. Regtest is necessary to test withdrawals because we need to mine blocks on demand in order to have block rewards to dole out. The CLN node doesn't currently do anything. Next steps are to stand up a second node and write some scripts to open a channel between them. This is a good area for a contributor to work autonomously because I am currently focused on other things so we won't be stepping on each others' toes.

I will keep working to onboard new contributors and build the knowledge base and tooling to help them thrive. I am aware that contributor time is very limited. Most folks only have a few hours a week they can dedicate to a side project. I probably won't attract a full time dev until I release a runnable 1.0 client. Right now it's a numbers game. I need to expand the top of the funnel before I will see any results at the bottom. Working with part time contributors helps me grow the skills and knowledge I will need to make this project self-sustaining.

Configs

I extracted the shared config logic into a dedicated crate. This allows me to define these options in one place and have disparate roles run the same code to access them. An example use pattern would be setting the mint url and port in a single file that the proxy and mint role can both access.

I also split the shared configs into pool and miner files to represent the different user profiles of the software. For example, many services on the pool side need to know how to access redis but the miner side roles will not have access. The split shared config design enforces this divide by ensuring that none of the miner side roles know how to access redis.

I also moved all of the role configs into a common /config directory at the root of the project. This makes managing these config options easy and clean for developers.

devenv.nix

This file orchestrates the whole environment, so it serves as the primary focal point for the hashpool project. As such, I put a lot of work into cleaning it up and making it easy to understand and work with. My work on the coinbase playground a few months ago leveled up my nix and devenv skills to make this possible.

It feels real good to pull up devenv.nix and see a nice clean work environment where I understand the purpose and necessity of every line. A place for everything and everything in its place.

Just Make it Easy

I also cleaned up the just file and added a number of recipes and recipe options that I found useful during the more involved development sessions. Here is the just --list output for the new recipes and options:

clean TYPE=""              # delete persistent storage; options: cashu, regtest, testnet4
db TYPE=""                 # Open cdk sqlite terminal client (wallet or mint)
default                    # list available just commands
generate-blocks COUNT="1"  # generate blocks in regtest
up mode=""                 # start development processes; pass 'backtrace' to enable RUST_BACKTRACE=1

Using a Real Database

Probably the most significant improvement since my last update was the move to a real database. I initially threw everything into an in-memory 'database' when I was sprinting to get ehash working. This was a fantastic shortcut because I could define data structures as hashmaps and didn't need to mess with any of the complicating factors that come with data persistence. But while I was playing with ehash I was not keeping my cdk dependency up to date. At some point cdk dropped support for this option so in order to keep up I needed to bite the bullet and implement actual database support.

Unsurprisingly, this was a big refactor and it uncovered a lot of issues. It took a while but I pushed through and got hashpool working on top of the latest commit in cdk. Now, Hashpool keeps two sqlite databases in its devenv state directory, one for the wallet and one for the mint. In the process of the refactor I found several bugs in hashpool and even a few in the cdk repo.

The whole project feels more solid and reliable as a result of fixing these bugs. I even upstreamed a cdk bug fix and I have another PR in progress to fix a race condition. It feels good to start contributing back and build up the ecash ecosystem.

Clean Up redis Dependency

The combo of a wallet db and the quote ID lookup API meant I was finally able to remove redis from the proxy service in these two commits. This was a holdover from the hacks I put in place in the sprint before btc++. Now the development environment process architecture matches what a production installation would look like. No more shortcuts that would create severe security issues in an actual deployment. No more violations of the split shared config file design.

Next Steps

A few days after I landed the cdk refactor thesimplekid merged his bolt12 payment option refactor. I spent a little time trying to refactor my ehash branch to work with this new architecture before accepting that it would be cleaner to just reimplement it. The hashpool3 branch was live in the Hashpool repo for less than a week before being obsoleted. lol 🤦

I am now working on reimplementing the ehash payment method on top of the new cdk architecture in the hashpool4 branch of my cdk fork. I think the end result of this refactor will be a new draft NUT spec for the mining share payment method. I probably won't take it out of draft until I get redemptions working but it will definitely help to get some early feedback on the spec. I have never created a spec before so this will be a new endeavor for me. LFG 🚀

Once I get the ecash stuff under control (which may take a while) I will turn my attention to the SRI repo. Hashpool is currently a fork of an old version of SRI. This is good enough for development purposes because I have worked to minimize the interface between the mining stack and the ecash stack. They only interact at a few key places.

But I will need to get up to date with the upstream repo well before a production release. I intend to turn Hashpool into a protocol extension that lives outside of the SRI repo and simply builds on the SRI binaries. This will be yet another large development undertaking in an unfamiliar realm, but now that I'm on the payroll the scope of the work ahead doesn't phase me.

OpenSats

My OpenSats grant for Hashpool and Axepool development was approved! 🙌 This is a massive personal win because it relieves the significant financial pressure of being self-funded. I have already noticed the improved productivity that comes from clarity of purpose and increased ability to focus.

But TANSTAAFL. Now I'm on the hook to deliver this thing. Axepool will be an interesting design challenge. I need to finish up the Sv1 proxy that johnny9 started developing months ago and incorporate it into the Hashpool repo as an option for deployment.

When building the Axepool binaries, this proxy role will replace all of the SRI processes. There will be two instances: one for the miner and one for the proxy pool. I'll need to add the appropriate ecash calls to the right places and it will be a second working ehash implementation.

I will need to accomodate the differences in implementation in the new cashu NUT. I'm thinking about how to do this in the back of my mind but I haven not yet begun development work. The good news is that my current work on cdk is equally applicable to both projects. I love double dipping!