BIP445: FROST Signing Protocol for BIP340 Signatures

[siv2r]

This PR adds a BIP for the FROST (Flexible Round-Optimized Schnorr Threshold) signing protocol. The development repository is at https://github.com/siv2r/bip-frost-signing.

There already exists RFC 9591, which standardizes the two-round FROST signing protocol, but it is incompatible with Bitcoin's BIP340 X-only public keys. This BIP bridges that gap by providing a BIP340-compatible variant of FROST.

This BIP standardizes the FROST3 variant (Section 2.3 of the ROAST paper). This variant shares significant similarities with the MuSig2 signing protocol (BIP327). Accordingly, this BIP follows the core design principles of BIP327, and many sections have been directly adapted from it.

FROST key generation is out of scope for this BIP. There are sister BIPs such as ChillDKG and Trusted Dealer Generation that specify key generation mechanisms. This BIP must be used in conjunction with either of those for the full workflow from key generation to signature creation. Careful consideration has been taken to ensure the terminology in this BIP matches that of ChillDKG.

There are multiple (experimental) implementations of this specification:

• The reference Python implementation included in this PR
• secp256k1-zkp FROST module (yet to implement the test vectors)
• FROST-BIP340 TODO: verify if this impl is compatible with our test vectors
• secp256kfun (implements ChillDKG with FROST signing) TODO: verify if this impl is compatible with our test vectors

Disclosure: AI has been used to rephrase paragraphs for clarity, refactor certain sections of the reference code, and review pull requests made to the development repository.

Feedback is appreciated! Please comment on this pull request or open an issue at https://github.com/siv2r/bip-frost-signing for any feedback. Thank you!

cc @jonasnick @real-or-random @jesseposner

[siv2r]

I'll fix the typos check soon

[siv2r]

I can see that GitHub's file changes view shows only one file at a time due to the large number of changes. This is because the reference implementation includes dependencies and auxiliary materials:

• The reference code uses secp256k1lab python library (vendored as a git subtree, ~20 files) for scalar and group arithmetic. I can remove this from the PR when the library is integrated into this repository (RFC: Integrate secp256k1lab v1.0.0 as subtree, use it for BIP-374 #1855).
• Auxiliary files include docs/partialsig_forgery.md (which I can move to a gist if preferred) and a test vector generation script (~1400 lines). I can exclude these if necessary.

[murchandamus]

This is just a first glance, but I noticed a few issues:

[murchandamus]

Thanks for the quick turn-around. It’s on my todo list to give this a more thorough look, but it might take a bit. If you can motivate some other reviewers meanwhile, that would also be welcome.

[siv2r]

If you can motivate some other reviewers meanwhile, that would also be welcome.

I've shared it with most of the Bitcoin cryptographers I know and will post it on Twitter and the Bitcoin dev groups I'm part of. Hopefully that will bring in more reviewers!

[DarkWindman]

Hi! Quite a remarkable job! We found a few minor issues, and correcting them would improve the overall specification of the BIP.

[Christewart]

As I mentioned on X i'm working on this, so you will likely see more comments in the future. Another nice-to-have would be a table of contents (example) as most other BIPs have this. Perhaps this is a limitation of the .md document vs .mediawiki. Not sure.

[siv2r]

Another nice-to-have would be a table of contents (example) as most other BIPs have this. Perhaps this is a limitation of the .md document vs .mediawiki. Not sure.

Yes, it's a .md issue, this bip initially had a manually written table of contents but was removed after #2070 (comment)

[murchandamus]

As I mentioned on X i'm working on this, so you will likely see more comments in the future. Another nice-to-have would be a table of contents (example) as most other BIPs have this. Perhaps this is a limitation of the .md document vs .mediawiki. Not sure.

Click there. ;)

[Christewart]

As I mentioned on X i'm working on this, so you will likely see more comments in the future. Another nice-to-have would be a table of contents (example) as most other BIPs have this. Perhaps this is a limitation of the .md document vs .mediawiki. Not sure.

Click there. ;)

Thank you! TIL :-)

[DarkWindman]

A few additional minor issues and questions.

[siv2r]

@DarkWindman thanks a lot for the review! I've addressed most of your review comments in a88f033.

[murchandamus]

From an editorial standpoint, it looks pretty good and like all the required sections are present. I have read the proposal only partially, and do not have the expertise to fully understand all aspects, so I cannot comment on the technical soundness and whether the Specification is complete and sufficient.

[murchandamus]

Let’s call this BIP 445. Please add an entry for your proposal in the README table, in the preamble update the BIP header to 445 and Assigned header to 2026-01-30, and update your documents file name as well as the auxiliary file directory.

[murchandamus]

@siv2r: Version 1.0.0 is usually reserved for the stage of the BIP that is advanced to Complete. You can find more guidance on Changelog Section and Version Header in BIP3.

[murchandamus]

I gave this another fast read. From an editorial perspective, this looks properly formatted and complete (when considering the footnotes and "Remarks on Security and Correctness" the stand-in for the Rationale section). I did not spend the time to fully understand the scheme and only skimmed the algorithm sections. I saw that there was a reference implementation included and that it had some tests. Given the many review comments, and extensive Changelog, it seems to have been read much more carefully by multiple other more qualified reviewers.

From an editorial perspective, I’d be happy to publish this whenever the author and reviewers indicate that the proposal is clear, comprehensive, and mature enough to do so.

[murchandamus]

@siv2r: It sounds like you think it’s ready for publication, some reviewers have indicated the same. Let’s merge this in a week (on or after July 6th) unless more things crop up. Or if you want it published before then, please let me know.

[siv2r]

Let’s merge this in a week (on or after July 6th) unless more things crop up

Sounds good! I'll do one final review this week, and will update here if anything comes up. Else we can merge on July 6th.

[DarkWindman]

Minor nit; everything else looks good to me!

[real-or-random]

Sorry for being late with a comment of this kind, but I think this should somehow take into account the "plausible attack on adaptive security of threshold Schnorr signatures" by Elizabeth Crites and Alistair Stewart (paper, talk).

tl;dr of the paper:

• The result of the attack (if possible, see caveats below) is that the attacker can forge a signature after compromising (and learning the secret shares of) fewer than t participants.
• It is not clear if there is an attack. It's only plausible in the sense that the attacker needs to solve a new computational problem from which nobody currently knows whether it's hard or not. This is unlike, e.g., the discrete logarithm problem on elliptic curves which has been studied for a long time, so that there's reasonable belief that it's hard.
• The attack requires the attacker to be adaptive, i.e., the attacker chooses whom to corrupt after seeing the results of key generation including the public shares. This is realistic; and I think users expect that the scheme remains secure if the attacker can do this.
• The attack requires t and n to be large. For example, a 131-of-196 setup is supposed to be easier to break than simply computing the discrete logarithm of the threshold public key but a 86-of-128 setup won't be affected (see Table 1 in the paper). Concretely, the authors suggest that the attack would be beneficial if effort(n, t) < 128 whereas effort is defined as in this Python code for secp256k1.

  from math import comb, log2
  def effort(n: int, t: int) -> float:
      c = comb(n, t-1)
      return -log2(c / ((2**256) + c))

The big question, of course, is what to do. I think there are two reasonable options:

1. Forbid affected parameters (n, t) entirely, and explain the rationale.
2. Only add a warning.

I tend to think that option 1 is better. Of course, that's a restriction in practice, but we can't just move on and pretend that everything will be fine. If someone wants to ignore the restriction, they can still do this, but then they're on their own.

[murchandamus]

Given these new review comments, I expect that we will not publish today. I’ll wait for your input, @siv2r.

[real-or-random]

After consulting with @elizabeth-crites, I have a clearer understanding now, and I should have mentioned also a second paper of her with Jonathan Katz, Chelsea Komlo, Stefano Tessaro, and Chenzhi Zhu (talk; immediately after the other talk in the same video).

In fact, the situation is better than I mentioned. It's not just that we don't know whether an attack exist.

The new paper defines a computational problem LDVR and proves that FROST is adaptively secure when LDVR is hard in addition to the discrete logarithm problem DL (or strictly speaking, its variant AOMDL). Then the paper proves that LDVR is – at least for parameters we're interested in (i.e., small enough n) – so hard that it's better for the attacker to attack DL instead.

Here's improved script that estimates the bit security (function effort) of an attack against LDVR. Here, t_c is the number of actually corrupted parties, i.e., the worst case is t_c = t.)

from math import log2, perm

BITS_GROUP_ORDER = 256

def myperm(n: int, k: int):
    if k >= 1:
        return perm(n, k)
    else:
        return 1

def table1(n: int, t: int, t_c: int | None = None):
    if t_c is None:
        t_c = t  # worst case
    return log2(myperm(n, 2 * t_c - t)/myperm(t_c, 2 * t_c - t))

# Check some numbers from Table 1 in https://eprint.iacr.org/2025/1061
assert table1(128,  96,  round(0.9 *  96)) -  79.24 <= 0.01
assert table1(256,  64,               64 ) - 203.57 <= 0.01
assert table1(1024, 512, round(0.6 * 512)) - 197.18 <= 0.01

def effort(n: int, t: int | None = None, t_c: int | None = None):
    if t is None:
        t = n // 2  # worst case
    return -(table1(n, t, t_c) - BITS_GROUP_ORDER)

DL has an (assumed) bit security of ~128, and to be on the safe side, we want that breaking LDVR is at least as hard, i.e., effort should return at least 128. So to determine safe parameters, the BIP could use rely on the effort function.

There's a cruder but much simpler restriction: As long as n <= 131, we'll always have effort >= 128. So a simple restriction (or recommendation) for the BIP could be simply to require n <= 131 (or maybe n <= 128 to be on the safe side and have a nicer looking number).

I'm pretty sure that 128 parties will be enough for all envisioned currently envisioned use cases of FROST.

[murchandamus]

@siv2r: Please let me know whether you want to go forward with the publication or are still making further updates. The recent review comments could also be addressed in a follow-up authored by another contributor.

[siv2r]

I'm working on fixing the recent review comments. Let's not publish until they're fixed.

[real-or-random]

nit: Do you mean "on the full set of n participants (u = n)" here? Could be clarified.

edit: On a further look, this is much more sublte. Moved the discussion to the dev repo at siv2r/bip-frost-signing#43 (comment).

[real-or-random]

I completed a full pass on the text. Nothing substantial and sorry again that my comments arrive that late in the process.

edit: Forgot to mention a "global" nit: The text uses "signer" and "participant" interchangeable. Sticking to one term would make things a tiny bit clearer (but this may be an annoying change to make at this stage).

[siv2r]

Tysm for the detailed review.

edit: Forgot to mention a "global" nit: The text uses "signer" and "participant" interchangeable. Sticking to one term would make things a tiny bit clearer (but this may be an annoying change to make at this stage).

This was fixed in the development repo recently. "Participants" refers to anyone involved in key generation, and "signers" to those participating in the current signing session. Will pull in the latest changes once the other review comments are resolved.