Socratic of Hard Knocks
I was invited to attend the Nashville Energy and Mining Summit (NEMS) at Bitcoin Park Jan 30th and 31st. This would be a great opportunity to talk with miners to spread the word and get feedback on my project.
The day before the conference I presented my project at BitDevs. It went horribly. I was planning to demo my project live but of course the demonstration gods picked that exact time to smite me with a build error. It totally threw me off my game. I tried to fumble through an explanation and troubleshoot the build error at the same time and ended up failing at both.
It wasn't a total loss. The audience was genuinely interested in the project and had good questions. I did manage to explain a few concepts, just not very well and not in a way that told a story. Instead it was kind of a jumble of ideas. The rest of the socratic seminar went great and I was able to contribute to the discussion.
In retrospect, the demo wasn't even important. I was just counting on it to have something for the audience to look at while I talked. I should have been mentally preparing to explain the project but instead I was totally focused on the unimportant thing and when it failed I was not able to recover. It's not a lesson I will soon forget.
Telehash and Grants
The rest of the conference went really well. The following day I was invited on stage during the Telehash to talk about Hashpool. This time I elected to skip the demo and just explain the project. It went much better! The beginning got cut off but you can watch the recording in this twitter post.
The 256 Foundation also announced a few grants including one that seems to closely match Hashpool. They are calling it Hydrapool and the idea is to have an easily deployable mining pool. Very similar to my layered mining pool concept!
In the weeks since the conference I have been considering an application and I have a few concerns. The grant description lists a team of 2 - 5. Do I need a team to apply? Do they have funding for a team? Also, I'm not an OSS licensing expert but it seems that my project's inherited MIT license might make it incompatible since 256 Foundation asks for GPL3.0.
My uncertainty around these questions has prevented me from applying for the grant. I still have open applications to Spiral and HRF and I am hopeful that one of them will come through. I'm also cognizant that I will need to attract developers for my project to succeed, and they will need to get paid for their work. Gary applied independently for the 256 grant and it seems to be going well. The best outcome is if we both receive grants and can both dedicate more time to the project so I have opted to take a wait and see approach with my outstanding grants.
NEMS
Once the conference properly began something kicked in and I went into high activity mode. I talked to everyone I could about mining, ecash, Hashpool, and other projects.
Cashu.me, the new PWA cashu wallet, made onboarding people as easy as cake. It really demonstrates the ease of use that the cashu protocol enables.
Pitching Hashpool requires explaining 3 or 4 new concepts to people. Starting with the user flow is key. Knowing the perspective of the person you are pitching to is also key. The pitch for professional miners is different from the pitch for hobbyist miners.
The fact that ecash is an old technology seeing a renaissance really resonates with people. Banking analogies work quite well to explain the concepts. Talking about free banking seems to combine these effects. Great intel! I will keep refining my message.
I also pitched Hashpool to the CEO of Foundry, he said it was a really good idea. Later I ecash pilled the president of OCEAN mining and set up a meeting to discuss Hashpool with their technical folks. I think I am starting to get on people's radar!
Project Tracking
Gary created a KanBan board and added a the first Hashpool issues to it. I spent a few days going hard and filled out the board with about 20 issues. It was honestly a little demotivating to see all the work that needs doing but at the same time it was good to unload all of that context from my brain to free up CPU cycles for other things. Once I started making progress on those issues the demotivating factor went away.
CDK PR
Once I was able to get back into the code I brought my cdk fork up to the latest release. I actually created a new branch and reapplied my changes when the rebase got too tricky but the end result is the same.
Next I opened a draft PR to discuss my changes. There are still some todo items to finish but I wanted to get feedback on my general direction of development.
We discussed the PR at a cdk meeting and I came away with a new and different development plan. I need to refactor my design to return the quote ID in the share accepted message instead of the blind signatures. This change simplifies the design quite a bit and lets me delete 1/3rd of the message flows I have already developed. Nice!
Currently on startup, Hashpool retrieves the keyset from the upstream pool. Then on share submission the proxy service sends blinded messages upstream to the pool, who sends the blinded signatures back downstream to the proxy to assemble into proofs, or ecash tokens.
With the new flow I don't need to send the blinded signatures back to the mining proxy service. Instead, the mint will produce the signatures asynchronously and the user wallet can retrieve them from the mint using the standard NUT-04 and NUT-20 protocols. This means less code for me to write and maintain, less surface area interaction between the ecash and mining protocols, and it solves two problems for me.
In the old design I needed a way to get the ecash tokens off of the proxy service and into the user wallet. I was planning to implement NIP-60 and upload the proofs to a nostr relay. With the new design I simply use the mint as the staging area instead of adding a new service to fill that role. This takes NIP-60 off the critical path of development and lets me tap into existing (and already implemented) wallet flows to solve my problem.
The other problem has to do with block invalidation. Sometimes when a user submits their own block template the pool can invalidate that share some time after accepting it because they find the block template invalid in some way. In an accountless ecash system you can't invalidate an ecash token after it has been issued. Invalidating only the share but not the token issued in exchange for it would inflate the token supply.
So we need a way to withhold the signatures until the share is fully validated. What a coinky dink! The cashu protocol developers already solved this problem with their quote system. This new design decouples minting ecash from the mining protocol messages. The pool can hold the blinded secrets as long as needed (potentially for a whole ecash epoch) to validate the user submitted block templates.
I don't plan to launch with user selected block templates but I do see it as a very important feature. Designing for it now will save me a big headache later on down the line.
Passphrase Magazine and hashpool.dev
After my presentation at btc++ I was approached by the editor of Passphrase Magazine and asked to contribute an article. I accepted, of course, and was given a March 1st deadline. With the dealine looming, I wrote a 1500 word introductory article with two simple diagrams explaining ecash and ehash.
As a general productivity strategy, whenever possible, I like to double dip and accomplish two goals at the same time. So I finished the final display issues with my website and added the passphrase article as the first explanatory article on the landing page. It should be a great place for me to send people who want to learn more.
In time, I can add more articles to explain the concepts in more detail. I can also add documentation, user guides, and whatever else comes up over time. The website is almost ready to launch. I can run it locally and it looks great. I just need to hook up some DNS records and set up github pages to start serving them. It will be a big upgrade for the project to finally have a landing page on the internet.