I hit my first milestone this week. I have successfully generated proofs in the translator proxy. To phrase it summarily: I can now generate ecash tokens in exchange for proof of work mining shares. LET'S GO BABY! \o/
I took a screenshot and posted it to nostr. Calle went nuts resharing on nostr and twitter, driving a lot of attention to my project.
I spent a lot of time trying to get variable length encoding working in order to send an entire keyset through SRI message transport. After trying a bunch of things without success I listened to reason (read: I listened to Gary) and pared the Sv2Keyset struct down to a single key. Once I removed the complexity of variable length data types it was fairly simple to get encoding to work using the existing encoding traits. I still need to revisit this but it doesn't need to stand in the way of constructing proofs.
With this core functionality working it was a small step to combine the blinded secret and blinded signature into a proof in the translator proxy. Right now I just log out the proof and store all the constituent pieces in various fields all over the codebase. My next development goal is to clean this up and encapsulate it into the cdk wallet where it belongs.
I also began to consolidate cashu specific logic into a new cashu.rs module in the mining protocol crate. This keeps the codebase more organized and will help when I eventually upgrade my project from an SRI fork to an SRI extension. Included in this crate is my first unit test to encode and decode the keyset struct.
I have begun work to encapsulate the proxy cashu logic into the wallet. I created two quick and dirty functions to add the keyset to the wallet db and retrieve it but I obviously missed something because retrieval always returns an empty list. Just today I added a unit test to my cdk fork to reproduce this behavior. Commits to this fork don't count on my github profile because it is a fork of another repo. This is dumb because it's a necessary step in the development process. It just goes to highlight how imperfect the green boxes are as a metric. As a result, I find myself working harder than intended on a Saturday afternoon just to get that green box. I need to come up with a strategy to improve this situation, else work on my cdk fork will get deprioritized. The dumbest thing would be to break it out from being an official fork just like I did for the hashpool repo. Frankly this is stupid, it doesn't need to be a top level repo. I could do other dumb things like opening PRs to myself. Need to evaluate possible solutions and pick the least stupid option.
The impact that my green box crusade has had on my development practices has not escaped me. I will probably turn my experience into a blog post at some point highlighting how Github's little developer productivity measuring widget changes development practices for better and for worse. It should make for interesting reading for those who use this metric and for those developers like myself who are evaluated based on it. Hopefully I can drive some positive change in the ecosystem with this work.
I received notice from OpenSats that my application was rejected on the same day that I shared my first milestone success. They provided zero actionable feedback in their rejection email, citing only "a very competitive applicant pool" for my rejection. I reached out through other channels and learned that given my ask amount they want to see a more firm budget and timeline, and a proof of concept. My contact suggested I keep working hard and apply again next month. Great! Will do! Not sure why they couldn't just put that stuff in the email. Surely, the quality of an applicant's personal network should not be a blocking factor in the grant process1.
Looking forward, I need to line up some relatively easy tasks to knock out day by day during the upcoming holiday season. The geen boxes must flow. I think setting up a website would be a good candidate here. I need to do it anyway and it's relatively easy to make daily tweaks while on holiday without seriously disrupting our vacation plans. I just bought the hashpool.dev domain name in preparation for this work.
Footnotes
-
In retrospect, this is a terrible argument. FOSS developers starting new projects need to attract devs and users and this is largely a factor of their networking skills. I'm not happy with the negative tone of this dev log but I will leave it as a historical artifact. Setbacks are to be expected. My friend J has a great spin on this: don't think of rejection as a step backward, instead count each one as a notch in your belt, a move forward towards your ultimate goal. I like this framing because nothing charges me up more than making progress toward my goal. ↩