Frost

---
name: bitcoin-frost
description: |
  FROST (Flexible Round-Optimised Schnorr Threshold): t-of-n threshold
  signing on secp256k1. n participants share a key via Distributed Key
  Generation (DKG) or trusted dealer; any t can produce a Schnorr
  signature. Differs from MuSig2 (which is n-of-n).
  USE WHEN: t-of-n threshold custody (e.g., 3-of-5 board signatures)
  with single-sig appearance on chain, federated services, multi-sig
  with availability.
allowed-tools: Read, Grep, Glob
---

# FROST — t-of-n Threshold Schnorr

FROST is the standard t-of-n threshold Schnorr signature scheme suitable
for Bitcoin. Like MuSig2, it produces a single 64-byte BIP340 signature
under one aggregated pubkey. Unlike MuSig2 (which requires all n parties
to sign), FROST allows any t ≤ n parties to sign.

## Key properties

- **t-of-n** — any t parties can sign, fewer cannot.
- **Single-sig appearance** — output looks like a regular Schnorr sig
  on a regular x-only pubkey.
- **Two rounds** in the FROST signing protocol (after one-time DKG).
- **No on-chain multisig** — saves bytes and improves privacy.

## Two phases

### Phase 1: Distributed Key Generation (DKG)

n parties run a DKG protocol to set up shares of a common private key
`d` corresponding to public key `P = d * G`. No single party ever
knows `d` itself.

DKG variants:
- **Pedersen DKG** (classical, 2 rounds with broadcast).
- **Trusted dealer** — one party generates `d`, hands shares out.
  Acceptable for some custody models.
- **DKG with verifiable secret sharing** — using Feldman / Pedersen
  VSS so parties can verify their shares.

After DKG, each party i has:
- Share `s_i` (Shamir share of `d`).
- Public verification key `S_i = s_i * G`.
- Group public key `P = d * G`.

### Phase 2: Threshold signing

When t parties want to sign message m:

#### Round 1 (commit)
Each signer i:
1. Generates two ephemeral nonces `(d_i, e_i)`.
2. Computes `(D_i, E_i) = (d_i*G, e_i*G)`.
3. Broadcasts `(D_i, E_i)` to coordinator.

#### Aggregation
Coordinator:
- Computes binding factor `ρ_i = H(i, m, ((D_j, E_j) for all signers))`.
- Computes group commitment `R = sum(D_i + ρ_i * E_i)`.

#### Round 2 (sign)
Each signer i:
- Computes Lagrange coefficient `λ_i` for the cooperating subset of
  size t.
- `c = TaggedHash("BIP0340/challenge", R.x || P.x || m)`.
- Partial sig: `z_i = d_i + ρ_i*e_i + λ_i * s_i * c   mod n`.
- Sends `z_i` to coordinator.

#### Aggregation
- `s = sum(z_i) mod n`.
- Final sig: `(R.x, s)`.

## FROST vs MuSig2

| Aspect | MuSig2 | FROST |
|--------|--------|-------|
| Threshold | n-of-n | t-of-n |
| Setup | trivial (just sum keys) | requires DKG |
| Round trip | 2 rounds + nonce setup | 2 rounds + DKG once |
| Partial sigs | per-signer-key contribution | Lagrange-based with subset selection |
| BIP | 327 | 445 (draft, PR open) |
| Bitcoin-specific | yes (BIP340 alignment) | yes (BIP340 alignment) |

Use **MuSig2** when all n parties always sign together (e.g., 2-of-2
joint custody).
Use **FROST** when subset signing is needed (e.g., 3-of-5 board, 2-of-3
multisig with social recovery).

## Implementations

- `frost-secp256k1` (Zcash / ZF FROST) — Rust reference.
- `secp256k1-frost` (bancaditalia/secp256k1-frost) — third-party Banca
  d'Italia (itcoin) fork of libsecp256k1 adding a `secp256k1_frost_*` C
  API; self-described "testing and experimentation" only, and **not** an
  upstream module as of September 2026 (see Status below).
- `chillDKG` (Blockstream research) — practical DKG with state recovery;
  now a submitted BIP draft (see Status below).
- `frostsnap` — Rust FROST stack behind the Frostsnap hardware wallet,
  MIT-licensed firmware + coordinator app (github.com/frostsnap/frostsnap).
- `frost-dalek` (Ristretto, not Bitcoin-relevant).
- Tools: `frost-cli` proof-of-concept.

## Status for Bitcoin

- **BIP 445** — "FROST Signing Protocol for BIP340 Signatures" (Sivaram
  Dhakshinamoorthy). Number assigned 2026-01-30; Status: Draft, spec
  version 0.10.0 (2026-08-26) as of September 2026. Submitted as
  `bitcoin/bips#2070` (opened 2026-01-03, still open — no BIP 445 file in
  the bips repo yet; the README table skips 443 → 446). Specifies the
  **FROST3** variant and adds what RFC 9591 lacks: BIP340 compatibility
  and key *tweaking* for BIP32 derivation and BIP341 Taproot. Key
  generation is explicitly out of scope for BIP 445.
- **ChillDKG BIP draft** — "ChillDKG: Distributed Key Generation for
  FROST" (Ruffing, Nick, Melnyk, Zhvanko, Dhakshinamoorthy), `Requires:
  445`, spec version 0.3.0-dev, no BIP number assigned yet. Submitted as
  `bitcoin/bips#2227` on 2026-07-30, still open as of September 2026.
  Dev repo: `BlockstreamResearch/bip-frost-dkg`.
- **RFC 9591 is not a drop-in for Bitcoin.** The IRTF published FROST as
  RFC 9591 (June 2024), including a `FROST(secp256k1, SHA-256)`
  ciphersuite — but its signatures are *not* BIP340-compatible, because
  BIP340 uses x-only public keys, and it specifies no key tweaking. An
  RFC 9591 library dropped into a Bitcoin wallet produces signatures
  Bitcoin will not accept. Use BIP 445 for signing; for key generation
  BIP 445 points at either ChillDKG or RFC 9591's own trusted-dealer
  setup (Appendix C).
- **No FROST module in either C library** (as of September 2026).
  bitcoin-core/secp256k1 master ships no FROST module — its module list
  is in [secp256k1/SKILL.md](../secp256k1/SKILL.md) — and secp256k1-zkp
  has only unmerged FROST pull requests, #138 (opened 2021-07-21) and
  #278 "FROST Trusted Dealer" (opened 2023-11-23), both still open. C
  callers have no upstream option; the Banca d'Italia `secp256k1-frost`
  fork above is not production-ready (last push 2026-06-11).
- Test deployments: Zcash uses FROST for orchard treasury; Bitcoin
  custodians experimenting (Coinkite, Lightning Labs research).
- Hardware wallet support: narrow, but no longer absent. **Frostsnap**
  ships a FROST-native Bitcoin hardware wallet — on-device DKG so the
  wallet secret never exists on any one device, arbitrary t-of-n,
  memory-safe Rust firmware on an ESP32-C3, MIT-licensed with
  deterministic builds; app/firmware v0.4.0 released 2026-08-25, units
  orderable with ~10-day delivery as of September 2026. The larger
  vendors had still not shipped FROST as of 2025.

## Security model

- **DKG correctness** — must use a robust DKG; bad DKG can leak `d`.
- **Nonce uniqueness** — same as MuSig2, never reuse nonces.
- **Subset binding** (`ρ_i` factor) — defeats the same Wagner-style
  attack that MuSig2 mitigates.
- **Identifiable abort** — modern FROST variants identify which party
  cheated (vs old "round failed, who?" problem).

## Use cases in Bitcoin

1. **Federated mints** (Fedimint guardians).
2. **Lightning Service Providers** with t-of-n key servers.
3. **Wallet recovery social schemes** (e.g., 2-of-3 friends).
4. **Multi-vendor multisig with availability** — currently P2WSH
   2-of-3 on chain; FROST collapses to single-sig on-chain.

## Common bugs

- Skipping verification step in DKG → silently corrupted shares.
- Reusing `(d_i, e_i)` nonces across signing sessions → key leak.
- Using non-Lagrange subset coefficients (e.g., linear weights) →
  produces wrong combined key.
- Mixing FROST and MuSig2 nonce derivation in a unified library and
  conflating tag domains.

## See also

- [musig2/SKILL.md](../musig2/SKILL.md)
- [schnorr/SKILL.md](../schnorr/SKILL.md)
- [../../l2/fedimint/SKILL.md](../../l2/fedimint/SKILL.md)