bip324 Status Update

It has been almost a year now since Rob and I started working on BIP-324 things, making this a good moment to share a progress update. Let’s look at the original goal, where we are at, and what’s up next.

The Goal

BIP-324 introduces transport level encryption to bitcoin’s peer to peer messaging. It defines the V2 version of the p2p protocol which is an encryption scheme, along with some message serialization tweaks to squeeze out some performance. V1 of the bitcoin p2p protocol is in plaintext which at first blush might not seem like such a big deal given that all information on the blockchain is public anyways. However, it is a massive privacy leak and allows ISPs to censor bitcoin users.

As of Bitcoin Core v26, the V2 protocol is enabled by default. This is great, but ideally every part of the bitcoin ecosystem is using encryption in order to throw a wrench in any sort of traffic analysis. And this includes light clients which use the same p2p protocol to pull information from the bitcoin network. The bip324 rust library was created to help fill this void.

Rob and I took an initial pass at hacking out the BIP-324 spec in rust, including all the underlying cryptography schemes. Once it seemed pretty viable, I had three goals for the library.

1. Push the lower level cryptography of the library down into rust-bitcoin for better visibility and potential use in other parts of the ecosystem.
2. Improve the use-ability and robustness of the bip324 library to make it easy to integrate into existing clients.
3. Push the library up into any clients that don’t have the bandwidth to adopt it themselves.

Current Libraries

Initially, all logic lived in the bip324 crate. But over the past year, chunks have been split out to better homes. This includes the chacha20_poly1305 crate which holds the base cryptography scheme.

chacha20_poly1305

There were two goals for splitting off the chacha20 cipher and poly1305 MAC implementations. The first was to just get more eyes on the implementations. And the second was to make it available to the rest of the ecosystem for other use cases, such as encryption over nostr.

The modules required quite a bit of love to get to the rust-bitcoin standard. They are highly focused on the bitcoin requirements, no extraneous features. They have zero dependencies, work in no_std environments, and have a relatively low MSRV (Minimum Supported Rust Version) for maximum compatibility.

There was also a pretty heavy re-write of the chacha20 cipher to allow it to take advantage of SIMD instructions for performance. It is currently written in a “portable” fashion, as in “portable across different CPU architectures”, where hints are given to the compiler to help it use the more performant instructions.

The next step for the library is to take the SIMD one level further and ensure the most popular CPUs have the most performant SIMD code possible.

bip324

While the heavy cryptography was moved out of the bip324 library, its user facing interface was refined for easy integration.

The bip324 crate follows the rust-bitcoin standard with minimal dependencies, is no_std compatible with a sans-IO approach, and a low MSRV. But optional features have been added, including a tokio feature for the popular runtime which makes it easy for a tokio user to adopt the library.

bip324 was also extended to support some of the more esoteric features of BIP-324 like the dummy packets for traffic shaping.

clients

As of today, two clients are making use of the bip324 library, kyoto and Floresta.

kyoto is a tokio-based light client also written by Rob which makes use of compact block filters. It has been the initial test bed for the bip324 external interface and has driven some of the helpful integration features.

Floresta is a full node implementation that is also making use of the tokio runtime. Modifying it to use bip324 was relatively straightforward, and the dispatch pattern used might be helpful for other clients. If helpful enough, it might be pulled down into the bip324 library itself.

Next Up

The focus in the short term is to make the chacha20_poly1305 crate as performant as possible. Better performance lowers the barrier for adoption and there is clearly some more juice to squeeze out of some manual SIMD code.

If you would like to integrate the bip324 crate please reach out! Happy to make something easier or iron out any bugs along the way.