FROST threshold signatures (RFC 9591 / BIP327 complement): is anyone working on this, and are new contributors welcome?

[HARSHVARANDANI]

Context

Now that MuSig2 (BIP327) has landed, libsecp256k1 has pretty solid support for n-of-n Schnorr multisig. One thing that seems like a natural follow-up in the threshold signature space is FROST (Flexible Round-Optimized Schnorr Threshold Signatures), which handles the t-of-n setting where any subset of t participants out of n can collaboratively produce a valid BIP340 Schnorr signature.

FROST was standardized recently in RFC 9591 (May 2024), including a secp256k1 ciphersuite. There is also ongoing work on Bitcoin-specific FROST and ChillDKG BIPs. This also aligns with the maintainers Jonas Nick and Tim Ruffing explicitly listing FROST as anticipated future work in their recent writeup on libsecp256k1's development.

A few questions

• Is anyone already working on a secp256k1_frost module, publicly or otherwise?
• If not, would this be a suitable area for a new contributor to work on with guidance?
• Would the expected scope be similar to MuSig2 initially, i.e. focus on signing and assume key shares are generated externally, leaving DKG out of scope?
• Are there any big design concerns or open questions around adding FROST support that contributors should be aware of before starting work?

Why it feels like a reasonable fit

• The final output is still a standard BIP340 Schnorr signature, so verification works with the existing Schnorr verification logic.
• There are practical Bitcoin-related use cases for threshold Schnorr signing: custody setups, Lightning-related applications, and multisig policies that stay private on-chain.
• Reading through src/modules/musig/, the secp256k1_musig_nonce_process nonce-binding approach looks like a natural template for FROST's per-signer binding factor computation, and the existing secp256k1_musig_keyagg_cache structure suggests a similar aggregated key context could work for FROST's group key state. There is an experimental implementation in bancaditalia/secp256k1-frost, it already implements FROST directly on top of libsecp256k1's primitives, which suggests the internal API surface is sufficient for a full implementation without needing new low-level additions.

Mainly trying to understand the current landscape before diving in. I do not want to duplicate ongoing work or open a premature PR without understanding the design expectations first.

If this is already being worked on, I would still be interested in contributing elsewhere around the project.

[furszy]

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

[HARSHVARANDANI]

Thanks for the pointer! I see @siv2r is actively working on the BIP spec for FROST signing. Is he also planning to head the C implementation for libsecp256k1, or is that open for a new contributor to take up?

If the latter, I'd be happy to first spend time contributing to the BIP spec alongside @siv2r to get properly familiar with the design before starting on the C module.

[furszy]

It would be unusual for someone to write a BIP without developing an implementation alongside it. You can ask in the repository.

[siv2r]

There's already a C implementation being worked on: BlockstreamResearch/secp256k1-zkp#278. @BEULAHEVANJALIN was working on it, the last time I reviewed the pull request.

[siv2r]

I'd be happy to first spend time contributing to the BIP spec alongside @siv2r to get properly familiar

Reviews are always welcome :)