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.

[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.

[vitrixLab]

This has made a good progress, and also the following blockers remain:

Security Parameter Restriction (Blocking)

The adaptive security attack (Crites–Stewart) is unaddressed. The BIP must restrict n ≤ 128 or implement the effort(n, t) check (per @real-or-random) in both the Security Considerations section and the reference implementation.

Terminology Sync

Changes distinguishing participants (key-gen) from signers (signing session) exist in the dev repo but haven't been pulled into this PR. Please sync.

Versioning

Per BIP3, the version should be 0.1.0 (Draft), not 1.0.0.

Pending Review Threads

Line-level comments (e.g., ValidateSignersCtx ambiguity, nonce coefficient details) remain open. Please resolve or push clarifying commits.

Once these are addressed, the PR will be ready for merge. CI is fine.

[murchandamus]

The comment by @vitrixLab is confusing to me. It seems to me that your Changelog section shows 0.8.0 as the latest version.

Since you are using a version in your Changelog, please also add the corresponding Version header.

[siv2r]

@murchandamus right, the changelog is at 0.8.0. I'll add Version: 0.8.0 to the preamble in the next push.

On the other points from @vitrixLab:

• Terminology sync and the open review threads: I'm working on a bigger change that came out of Tim's comment in the dev repo (Is the current SignersContext design optimal? siv2r/bip-frost-signing#43). It introduces a threshold setup and validation of the participants' context. Once that's merged there, I'll sync everything over here, including the participant/signer terminology fix.
• Adaptive security: I'll resolve this one too.

Those are the two main things open on my end. I expect both to be done around the middle of next week.

[murchandamus]

Okay, thanks for the update.

[vitrixLab]

BIP-445 / PR #2070 — Technical Review

Review status: Technical review supported; clarification requested before merge

I reviewed BIP-445 against the pinned PR state and the companion ChillDKG work, with particular attention to the BIP340 adaptation, signing-context validation, DKG interoperability boundary, and the current adaptive-security literature.

1. BIP340/FROST interface

The PR description clearly establishes the intended role of BIP-445: adapting the FROST signing protocol to Bitcoin's BIP340 X-only public-key setting and standardizing the FROST3 variant. Key generation is deliberately outside the scope of BIP-445, with ChillDKG and trusted-dealer generation serving as companion mechanisms.

This separation appears intentional and is technically reasonable.

2. Signing-context integrity and validation

SignersContext participates in the signing/session-value computation, so its integrity is an important protocol boundary. The specification itself warns that GetSessionValues and its stored result must be protected from untrusted modification.

The existing ValidateSignersCtx definition is also more explicit than a superficial reading might suggest. It:

• rejects duplicate identifiers;
• checks that the key material reproduces the threshold public key; and
• is invoked by Sign, PartialSigVerify, and PartialSigAgg.

Importantly, the specification distinguishes functional compatibility validation from guaranteeing the security of the underlying key-generation protocol. That distinction should be preserved in the final wording/documentation.

3. ChillDKG interoperability boundary

The ChillDKG work explicitly identifies BIP-445 as its intended signing counterpart and identifies DKGOutput alignment as an interoperability issue. In particular, the ChillDKG description states that its DKGOutput structure needs to match what BIP-445 expects as input.

I therefore recommend making the DKG-output → signing-context contract sufficiently explicit that independent implementations can determine the exact compatibility requirements without relying on implementation-specific assumptions.

4. Adaptive-security considerations

Recent CRYPTO 2025 work reports adaptive-security concerns relevant to threshold Schnorr/FROST constructions, including analysis involving stronger computational assumptions.

I am not asserting that BIP-445 currently contains an exploitable vulnerability, nor that a particular parameter restriction automatically applies to BIP-445.

The narrower review request is:

Please explicitly state the security model, computational assumptions, and applicable parameter treatment at the BIP-445/ChillDKG boundary, or explain why the cited adaptive-security results do not apply to the construction as specified.

This would make the security claim auditable rather than leaving the applicability relationship implicit.

5. Message semantics

The BIP-445 session-value computation incorporates m into the BIP0445/noncecoef hash input. Consequently, the specification/API should make the distinction between:

• a message being absent; and
• a message being present but zero-length

completely unambiguous.

I am not asserting a particular 00/0100 encoding. That specific encoding claim remains unverified in the current review and should not be treated as a normative BIP-445 fact without a source.

Requested clarifications

Before finalization, I recommend confirming four points:

1. Security model: explicitly identify the adaptive-security model and assumptions applicable to BIP-445.
2. ChillDKG boundary: explicitly define the required DKG-output/signing-context compatibility contract.
3. Validation semantics: preserve the distinction between ValidateSignersCtx's functional checks and key-generation security guarantees.
4. Message semantics: explicitly specify absent-vs-present-empty message semantics without relying on an unsourced byte-encoding interpretation.

Overall assessment

I do not see evidence from this review supporting a claim of an existing exploitable vulnerability in BIP-445. The principal issue is specification-level clarity and security-model explicitness, particularly at the BIP-445 ↔ ChillDKG interface.

These points are intended as clarification/strengthening requests rather than a claim that the underlying FROST/BIP340 construction is unsound.

[vitrixLab]

BIP-445 / PR #2070 — Technical Review

Review status: Technical review supported; clarification requested before merge
. . .
. . .

Overall assessment

I do not see evidence from this review supporting a claim of an existing exploitable vulnerability in BIP-445. The principal issue is specification-level clarity and security-model explicitness, particularly at the BIP-445 ↔ ChillDKG interface.

These points are intended as clarification/strengthening requests rather than a claim that the underlying FROST/BIP340 construction is unsound.

Reproducibility / assessment record

This supplements the technical review above with the exact evidence trail.

I preserved the upstream bip-frost-signing baseline at:

f7de4568f2497b40bd85bb8fb40da32c05b68d72

The same commit is mirrored at:

vitrixLab/bips:bip-frost-signing

A separate assessment branch was created from that baseline without modifying the implementation branch:

assessment/bip-445-technical-review

Initial assessment checkpoint:

c343b6aea204b718dfc856ecce258cdf2723b518

Assessment record

No BIP-445 implementation or specification changes were made as part of the review.

[real-or-random]

3. ChillDKG interoperability boundary

The ChillDKG work explicitly identifies BIP-445 as its intended signing counterpart and identifies DKGOutput alignment as an interoperability issue. In particular, the ChillDKG description states that its DKGOutput structure needs to match what BIP-445 expects as input.

This is tracked in the ChillDKG dev repo: BlockstreamResearch/bip-frost-dkg#157

5. Message semantics

The BIP-445 session-value computation incorporates m into the BIP0445/noncecoef hash input. Consequently, the specification/API should make the distinction between:

* a message being absent; and

* a message being present but zero-length

completely unambiguous.

This is bullshit. The message is a mandatory argument and thus always present.

[murchandamus]

I’m not as close to the material as @siv2r or @real-or-random, so please correct me, if I’m getting a wrong sense here, but the contributions from @vitrixLab read like low-quality slop to me.

@vitrixLab: If authors want a document to be processed by an LLM, they can point their own agents at it. Most of the value of LLM input is generated in combination with the human assessment and refinement in the loop, which seems to be lacking here. If you are not familiar with this topic and simply pointing an LLM at this document, you’re not helping, you’re emitting noise. Ultimately, the user is responsible for the content and quality of the comments. Please either step up the quality of your contributions or cease posting in this repository.

[seedhammer]

Does the protocol protect against exfiltration attacks? If not, why not? The protocol is already interactive, and adding anti-exfil as an optional extention will likely limit uptake. In particular, malicious signing devices will simply not implement the extension.

Edit: with builtin anti-exfil, this protocol might very well become de facto even for n=1 singlesig wallets.

[siv2r]

BIP could be simply to require n <= 131 (or maybe n <= 128 to be on the safe side and have a nicer looking number).

$n$ is now capped at 128 (v0.10.0). I considered allowing larger $n$ for the $(n, t)$ pairs that stay hard instead, but the allowed $t$ (the BIP's threshold, one more than the $t$ in your script) shrinks fast as $n$ grows: at $n = 132$ thresholds 65 to 69 already fail, at $n = 256$ only $t \le 30$ or $t \ge 228$ pass, and at $n = 1024$ only $t \le 19$ or $t \ge 1007$. That rule is harder to state and implement, so a flat cap seemed simpler. Another option is to implement the effort(t, n) >= 128 check (assuming tc = t - 1) inside ValidateThresholdInfo, without the n <= 128 cap.

The other change is the redesign from siv2r/bip-frost-signing#43 (v0.9.0). ThresholdInfo holds the key material from key generation, including all the public shares you know. Not all of them take part in a signing session: the coordinator picks the signers, and only their identifiers and public shares go into the SessionContext. Before, the signer set was an input to the session, so it was fixed before round 1. Now it can be chosen just before round 2.

[siv2r]

Does the protocol protect against exfiltration attacks? If not, why not?

I've opened the issue siv2r/bip-frost-signing#60 to discuss what the bip should do regarding this.