2024.09 Vol.2

// Spiral Q3 Report #Bitcoin

The Spiral Series

  1. 2024.08 Vol.2 // Spiral Goals
  2. 2024.09 Vol.2 // Spiral Q3 Report
  3. 2025.01 Vol.3 // Spiral Q4 Report

Heads down on BIP324 encryption library work.

push down the cryptography

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.

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.