Quarterly Progress Report #1

What I worked on: May, June & July (2024)

Over the last few months, I've been focused on writing a specification for a BIP340-compatible FROST signing protocol, which we're calling BIP FROST Signing. The first draft is almost there, packed with everything you’d expect from a BIP—detailed design, reference code, and security considerations.

https://github.com/siv2r/bip-frost-signing

To make things a bit smoother for our reviewers, I’ve included an illustration that lays out an overview of the signing process. Hopefully, this visual will make things a lot easier to process. I remember struggling to get a clear picture of BIP327 in my initial readings.

Given how closely FROST and MuSig2 protocols resemble each other, drafting BIP FROST Signing had me revisiting BIP 327 repeatedly—so many times, in fact, that I could probably recite it in my sleep! On the plus side, this deep dive helped me spot a few issues, the most significant one being an error in one of their test vectors. I’ve already sent a patch to fix it: https://github.com/bitcoin/bips/pull/1591. These fixes earned me a shoutout in the acknowledgments section of BIP327!

I left some initial review comments on the MuSig2 and FROST Trusted dealer PRs. I avoided a thorough review of the FROST PR because the BIP specification was still in its early stages at that time.

We also progressed quite a bit on the Schnorr adaptor signatures specification. Here are a couple of highlights from my contributions:

1. Improved algorithm for the extract_adaptor API—more details here.

2. A thorough revamp of test vectors for much better coverage—more details here.

I’m waiting for the author to address the review comments on the secp256k1-zkp adaptor pull request.

Reflections

I seriously underestimated the time it would take to write the BIP, thinking a quick tweak of BIP327 would do the trick! In reality, It required me to start with the FROST & ROAST papers, dig into BIP327, code the implementation and test vectors, and figure out whether the attacks mentioned in BIP327 applied to our BIP. As you might guess, getting a review-ready draft took longer than I thought. Thankfully, the BIP is still on track with the crazy timeline laid out in my project proposal. Starting in February turned out to be a lifesaver!

When writing the BIP, I also realized that my foundations on provable security are shaky. I’ll need to work on that, but it's not a top priority at the moment since the upcoming tasks won't demand it.

Since the FROST Trusted Dealer PR has yet to be merged, the Rust bindings project will be delayed. But I'm optimistic it won't be too bad. With BIP DKG and BIP FROST Signing almost finished, developers are speeding up their implementation efforts. Plus, we've scheduled a recurring FROST sync meeting starting on July 22 to keep everything on track.

After discussing the hacspec project with Jonas Nick, we agreed that merging the FROST implementations should take priority over it because of its greater real-world impact. So, I’ve decided to hit pause on the hacspec project for now and will revisit it later to see if it’s worth including in the BIP.

Next Steps

I shared the BIP FROST Signing draft with the Bitcoin development mailing list and plan to address any reviews or suggestions I receive.

In the coming months, I’ll review the BIP DKG, and FROST trusted dealer PR and lend a hand to get them ready as soon as possible. Once that’s sorted, I’ll shift my focus to the Rust bindings project. If I find any extra time in between, I’ll revisit my long-neglected batch verification project, which is in desperate need of a rebase, and also take a look at other secp256k1 pull requests.