Spiral 2024-2025

After spending a few years in startup-land at Mash, it felt too bitcoin-adjacent. I wanted my cycles to go directly to the ecosystem. So I joined the Chaincode BOSS program as a forcing function to dive into the space and that lead to me getting my first year long grant from Spiral. The following is my goal for the year and the significant outputs by quarter.

Goal

I want to increase the use of encryption in the bitcoin ecosystem to move the ball forward a few yards on the censorship-resistant front. BIP324 is the starting point and implementing the spec in rust with the BIP324 library was the first step. There are three areas I want to keep pushing on for the library.

1. Push the cryptography primitives of the library “down” into rust-bitcoin.
   • The library has zero-dependencies and is no-std friendly, requirements for rust-bitcoin. But ideally, the cryptographic primitives like the ChaCha20 cipher and Poly1305 MAC would live somewhere closer to the core of rust-bitcoin. This would get more eyes on the code, always a good thing, but it would also let other parts of the ecosystem easily use them.
2. Improve the use-ability and robustness of the library.
   • The library is fully functioning, but the API can be improved with client feedback and there are a few subtle parts of the spec which could be implemented better.
3. Push the library “up” into any clients that don’t have the bandwidth to adopt it themselves.
   • Ideally the library is so easy to use it is just instantly adopted, but might not be realistic in all cases.

I’ll also be keeping logs of my journey over the year. This is mostly for me, writing things down in my own words is how I “lock in” something hard to wrap my head around. But I am making the notes public on the off chance they help just one other developer go from 0-to-some knowledge of the cryptography in bitcoin. We ain’t all going to be Satoshi level hackers, but I think it is valuable to spread the knowledge to maintain these base level primitives.

2024 Q3

push down the crypto

Move the cryptographic primitives in the BIP324 library, namely the ChaCha20 stream cipher and the Poly1305 MAC, into rust-bitcoin. The centralizes the primitives and makes it easier to use them in the ecosystem in non-BIP324 contexts, such as Payjoin’s peer to peer channel.

• [CODE] Improve Keyed Hash Function in rust-bitcoin/hashes
  • The ChaCha20Poly1305 pull request review revealed some bad assumptions of the only keyed hash implementation, SipHash, in rust-bitcoin. It defaulted to being used like an un-keyed hash function which could possibly be a foot-gun for users if they are not careful. I cleaned this up and refactored some interfaces so that the next keyed hash function, hopefully Poly1305, would be easier to integrate with the interfaces.
• [CODE] Migrate ChaCha20Poly1305 to rust-bitcoin/chacha20_poly1305
  • This is the big one and has taken many iterations to get approval. One of the big new requirements was making the code SIMD-friendly for extra performance.
• [LOG] Bringing the AEAD Up To Snuff
  • Learned quite a bit bringing the big ChaCha20Poly1305 patch into rust-bitcoin.
• [LOG] Making use of SIMD
  • This includes the performance benefits of SIMD and why they are relatively easy to capture in the cryptographic use case. I think the SIMD complexity is a good example of knowledge that needs to be spread to as many developers in the space as possible.

handle decoy packets

The BIP324 spec mentions “decoy” packets a bunch. This allows either side of the encrypted channel to send packets with a decoy flag which are meant to be ignored. They just help hide the shape of information being passed over the channel. A subtly of this feature is a party can start sending decoy packets before the handshake is even completed. Currently, even the bitcoin-core implementation skips actually supporting sending them here, but our rust implementation should still handle the case. I got a bit of clarity on this feature from sipa on bitcoin StackExchange.

• [CODE] Receive Decoy Packets in rust-bitcoin/bip324
• [CODE] Send Decoy Packets in rust-bitcoin/bip324
  • This includes a lot of minor tweaks as the API is iron’d out.

etc

• [LOG] Quadratic Residue
  • A lot of bitcoin stack exchange answers assume knowledge of quadratic residue. It wasn’t obvious after a quick wiki page read what was going on, so I did a dive on why square roots still exist in a finite field. The property is leveraged a bunch.
• [LOG] Point Encoding
  • Another subject on bitcoin stack exchange with a lot of subtle assumptions of knowledge. How, when, and why a public key is encoded is extremely context dependent with a lot of ongoing chatter for systems built on top of bitcoin.
• [LOG] Encryption in Nostr
  • BIP324 brings strong encryption to bitcoin nodes communicating with each other. Ideally, this level of encryption was the default in other contexts of the bitcoin ecosystem for the best censorship resistance. A use case I am very interested in is Payjoin V2 where two parties collaborate to create a bitcoin transaction. I was curious what the challenges are to using something like Nostr as the encrypted communication channel. Dan Gould gave a nice shout out for this post.
• [LOG] Nix
  • Dove into the Nix ecosystem in order to migrate my home server nodes over to Nix management. It has a lot of buzz in the bitcoin community and it is easy to see why, it helps make maintaining complicated things easier. The nix-bitcoin project is super solid, I hope I can contribute to that someday.

2024 Q4

AFK for a bit this quarter due to the addition of a new family member!

asynchronous api

The BIP324 library is written in a “sans-io” style which make it extremely adaptable to any runtime a caller happens to be using. Nowadays though, asynchronous runtimes are the most popular for light clients, so adding a usability wrapper around the sans-io primitives to make it easier to integrate the library in these contexts.

• [CODE] Async Protocol Interface in rust-bitcoin/bip324
  • Add the high level AsyncProtocol interface for callers using asynchronous runtimes.
• [CODE] Tokio Integration in rust-bitcoin/bip324
  • Make it even easier for callers using the popular Tokio asynchronous runtime.
• [LOG] Cancellation Safety
  • There are come traps using futures and buffers. Cancellation issues were very obvious in the BIP324 library.

replace crypto implementations

The cryptography primitives worked on in Q3 have made their way into rust-bitcoin/hashes and rust-bitcoin/chacha20_poly1305. BIP324’s internal versions can now be dropped and replaced by these dependencies. The BIP324 code can focus just on the protocol specific logic.

• [CODE] Switch the HKDF Implementation in rust-bitcoin/bip324
• [CODE] Switch the ChaCha20 Poly1305 Implementation in rust-bitcoin/bip324

v2 serialization

Another bit of logic to push down into rust-bitcoin/bitcoin is how V2 messages are encoded over the wire. The last “dangling” module, cleaning it up leaves the library in an extremely focused state.

clients

With performance upgrades in place and easier integration interfaces available, let’s get this thing into some light clients!

• [CODE] Upgrade bip324 to v0.6.0 in rustaceanrob/kyoto
  • Rob was nice enough to upgrade to the v0.6.0 version of the bip324 library in the kyoto client. It shows off the new async API and hopefully is a blueprint for other clients.

etc

• [LOG] Network Metadata Leakage
  • Took another pass at the general issue of network privacy. It is an interesting problem that appears to effect all levels of the sovereign stack, from payjoin to ecash mints.
• [LOG] Commitment Schemes
  • The next step in my cryptographic journey as I build up to an understanding of things like Bulletproofs.
• [LOG] Blind Signatures and [LOG] Ecash
  • Checked out the cryptography behind ecash and how ecash mints fit into the bitcoin ecosystem. Interesting how network metadata privacy is an issue here too.