Spiral Q1 Report

Working on the “full stack” of bip324, from the end clients all the way down to the encryption cipher.

floresta

I extended the floresta full-node implementation with encrypted transport using the bip324 library. Also sunk into some the nix integration getting the functional python tests running.

• [CODE] Add V2 p2p support // Initial support for BIP-324 for Floretsa. Very cool! Explored some different integration patterns and liked the static dispatch approach I settled on here. May be helpful for more integrations in the future.
• [CODE] Transport protocol visibility // Follow up with some nice visibility improvements for maintainers and users.

bip324

Cleaned up the library and released version v0.7.0.

• [CODE] Relax tokio version requirements // Relaxed dependency requirements which allows the library to be more flexible for callers.
• [LOG] Dependency Version Constraints // Documented why the version constraints were painful to callers since the pattern wasn’t immediately clear to me.
• [CODE] Rename “async” feature to “futures” // Cleaned up feature flags to match conventions.

chacha20

New tests exposed some quick wins to improve the cipher’s performance.

• [CODE] Improve chacha20 cipher performance // Fixed a performance bug (doing too much work) and refactored minor things for some modest, but measurable, performance improvements.
• [LOG] Manual SIMD // Bit of a work in progress, but exploring further optimizations taking advantage of more complex SIMD patterns.

kyoto

Rob has been hard at work making Kyoto the premier rust-based bitcoin light client. I think it has potential to be a great test bed for experimenting with different p2p techniques for things like peer management, block syncing, and filter management. I got the lay of the land through some minor refactors and build improvements.

• [CODE] Deprecate core module // Refactored code into more descriptive modules with clearer ownership.
• [CODE] New msrv job to isolate build tools // Added a CI check to ensure library met its MSRV requirement.

onion routing on nostr

I have been learning about network level privacy in my Network Metadata series and it is leading me to think that there should be a “bitcoin native”-ish privacy preserving communication channel. By bitcoin native, I mean one that adds very few dependencies and fits bitcoin specific use cases. Nostr uses the same cryptography primitives by design, including ChaCha20Poly1305, and it might be good enough for bitcoin’s low bandwidth/high value use cases such as cooperative transaction building.

• [LOG] Onion Routing on Nostr // Tracked down the years-long history of different onion-routing proposals in nostr. At the end, I propose a new version which attempts to be the simplest and most up-to-date.
• [CODE] Add NIP-4A Event Onion Routing // Up to date onion routing proposal for nostr. I am not sure if I am going to push hard on this since I am not focused on nostr at the moment, but figure the concise recap is helpful no matter what.
• [LOG] TLS // Learning about why TLS is still a little too heavy weight for some use cases.