Schnorr & MuSig2 Reference: Multi-Party Signing on Bitcoin

Schnorr Signatures on Bitcoin (BIP340)

Schnorr signatures replaced ECDSA as the signature scheme for Taproot outputs when the soft fork activated at block 709,632 on November 14, 2021. BIP340, authored by Pieter Wuille, Jonas Nick, and Tim Ruffing, specifies 64-byte Schnorr signatures over the secp256k1 curve. The scheme uses x-only public keys (32 bytes instead of 33 for compressed ECDSA keys) and produces signatures consisting of a 32-byte nonce commitment R and a 32-byte scalar s.

The verification equation is s·G = R + e·P, where e = Hash(r ‖ x(P) ‖ m). The critical property that distinguishes Schnorr from ECDSA is linearity: given valid signatures (s₁, s₂) for public keys (P₁, P₂), they can be summed to produce a valid signature for the combined key P₁ + P₂. This linearity is the mathematical foundation for key aggregation, multi-signatures, and threshold signing schemes like MuSig2 and FROST.

Schnorr vs ECDSA

The following table compares BIP340 Schnorr signatures with the ECDSA scheme used in legacy and SegWit v0 outputs.

Non-malleability eliminates a class of transaction malleability issues. Batch verification allows nodes to validate blocks faster during initial block download. For a deeper look at how Taproot leverages these properties, see Taproot and Schnorr Signatures Explained.

Key Aggregation and MuSig2 (BIP327)

BIP327 specifies MuSig2, a two-round multi-signature protocol that allows n parties to produce a single Schnorr signature indistinguishable from an ordinary single-signer Taproot key-path spend. The protocol was designed by Jonas Nick, Tim Ruffing, and Yannick Seurin (published at CRYPTO 2021) and formalized as a BIP by Nick, Ruffing, and Elliott Jin.

MuSig2 is an n-of-n scheme: every designated signer must participate to produce a valid signature. The on-chain result is a standard 64-byte signature and a single 32-byte public key, regardless of how many parties signed. This means a 3-of-3 MuSig2 spend is indistinguishable from a solo spend, providing significant privacy and fee savings over traditional OP_CHECKMULTISIG multisig.

Key Aggregation (KeyAgg)

Before any signing occurs, participants run the KeyAgg algorithm. Each signer's public key is multiplied by a coefficient derived from a hash of all participants' public keys. This produces a single aggregate public key that commits to the entire group. The coefficient prevents rogue-key attacks where a malicious participant crafts their key to cancel out honest signers.

Two-Round Signing Protocol

MuSig2 reduced the signing rounds from three (in the original MuSig) to two, which is critical for interactive protocols like Lightning channels:

1. Nonce exchange: each signer generates a pair of nonces and broadcasts the public nonce commitments to all other signers.
2. Partial signature exchange: each signer computes a partial signature using their private key and the aggregated nonce. Partial signatures are combined into the final 64-byte Schnorr signature.

Security warning: If a signer ever reuses a SecNonce across two different signing sessions, a co-signer can extract their private key. BIP327 implementations must generate fresh nonces for every session.

MuSig2 Security Model

MuSig2 is proven existentially unforgeable under the Algebraic One-More Discrete Logarithm (AOMDL) assumption. The protocol supports concurrent signing sessions, meaning a signer can participate in multiple signing operations simultaneously without compromising security, provided nonces are never reused.

FROST: Threshold Schnorr Signatures

While MuSig2 requires all n signers, FROST (Flexible Round-Optimized Schnorr Threshold signatures) enables t-of-n threshold signing: any t participants out of n can cooperate to sign, even if the remaining n-t signers are offline. The resulting signature is still a standard 64-byte Schnorr signature indistinguishable from a single-key spend on-chain.

FROST was introduced by Chelsea Komlo and Ian Goldberg in 2020 and standardized as RFC 9591 (published June 2024). The RFC covers the general protocol, but Bitcoin-specific adaptations are needed for Taproot tweaking and x-only public keys. A dedicated FROST Signing BIP draft (by Sivaram Dhakshinamoorthy) and a companion ChillDKG BIP draft (by Blockstream Research) for distributed key generation are under active development.

FROST's key generation is significantly more complex than MuSig2's KeyAgg because it requires a Distributed Key Generation (DKG) ceremony where participants jointly generate key shares using Shamir's secret sharing. Once key shares are established, the two-round signing protocol is similar in structure to MuSig2. For a detailed look at FROST, see FROST Threshold Signatures Explained.

Signing Scheme Comparison

The following table compares the three main approaches to multi-party signing on Bitcoin: legacy ECDSA multisig, Schnorr-based MuSig2, and FROST threshold signatures.

For practical guidance on choosing a multisig configuration, see the multisig planner tool. For a broader comparison of signing approaches and wallet types, see Bitcoin multisig setup comparison.

Implementation Landscape

MuSig2 has moved from specification to production deployment across several categories of Bitcoin software:

• libsecp256k1 (bitcoin-core/secp256k1) includes an optional MuSig2 module implementing BIP327, added in 2024
• secp256k1-zkp (Blockstream Research) provides MuSig2 with adaptor signature support for Lightning and atomic swap use cases
• Bitcoin Core PR #31244 implements MuSig2 descriptor parsing per BIP390, under active development
• BitGo deployed the first production MuSig Taproot multisig wallet and reported approximately 30% fee savings per input
• Ledger added MuSig2 support in Bitcoin app v2.4.0 (April 2025)
• Nunchuk launched a Taproot Multisig wallet using MuSig2 in 2026 (beta)
• LND includes a MuSig2 API since v0.15.0-beta and uses it for Simple Taproot Channels since v0.17 beta
• Lightning Loop uses MuSig2 for Loop In swap funding since February 2025

FROST implementations are earlier-stage. The ZcashFoundation/frost Rust library includes a frost-secp256k1-tr crate for BIP340/BIP341 compatibility. Blockstream Research has open PRs adding FROST to secp256k1-zkp. Blockchain Commons published educational tooling and a FROST-Hubert CLI for ceremony management in late 2025. No production Bitcoin wallet has deployed FROST on mainnet as of mid-2026.

MuSig2 in Lightning and Layer 2 Protocols

MuSig2 is particularly valuable for the Lightning Network because channel funding outputs are inherently 2-of-2 multisig. With MuSig2, channel opens and cooperative closes appear as ordinary single-key Taproot spends, improving both privacy and fee efficiency.

LND's Simple Taproot Channels use MuSig2 for the funding output and cooperative close path. As of mid-2026, these channels operate as private (unadvertised) channels. The Gossip 1.75 protocol upgrade, which will enable public Taproot channel announcements, is under development. LDK is also working toward MuSig2 integration, pending stable Rust bindings for libsecp256k1's MuSig2 module.

Layer 2 protocols like Spark benefit from Schnorr-based signing because cooperative state transitions can be compressed into a single signature on-chain, reducing the per-transaction cost of operating off-chain payment channels and state machines.

Related BIPs and Standards

The Schnorr/Taproot/MuSig2 stack spans several interconnected specifications:

• BIP340: Schnorr Signatures for secp256k1 (deployed November 2021)
• BIP341: Taproot spending rules, defining key-path and script-path spends (deployed November 2021)
• BIP342: Tapscript validation rules for script-path spends (deployed November 2021)
• BIP327: MuSig2 for BIP340-compatible multi-signatures (active)
• BIP390: musig() descriptor key expression for wallet integration (active)
• FROST Signing BIP draft (siv2r/bip-frost-signing): Bitcoin-specific FROST protocol (version 0.3.5, January 2026)
• ChillDKG BIP draft (BlockstreamResearch/bip-frost-dkg): Distributed Key Generation for FROST (in development)

For a reference of all Bitcoin opcodes relevant to signature verification, including OP_CHECKSIG and its Tapscript variant OP_CHECKSIGADD, see the Bitcoin opcode reference.

Frequently Asked Questions

What is the difference between MuSig2 and FROST?

MuSig2 is an n-of-n scheme: all designated signers must participate to produce a signature. FROST is a t-of-n threshold scheme: any subset of t signers out of n can sign. Both produce standard 64-byte Schnorr signatures indistinguishable from single-key spends. MuSig2 has simpler key setup (KeyAgg), while FROST requires a Distributed Key Generation ceremony. MuSig2 is production-ready; FROST remains experimental on Bitcoin.

How does Schnorr key aggregation work?

Each participant's public key is multiplied by a coefficient derived from a hash of all participants' keys (the KeyAgg algorithm in BIP327). The resulting weighted keys are summed to produce a single aggregate public key. This coefficient prevents rogue-key attacks where a malicious signer crafts their key to cancel others. The aggregate key is a standard 32-byte x-only public key usable as a P2TR output.

Why is nonce reuse dangerous in MuSig2?

If a signer uses the same SecNonce in two different signing sessions, a co-signer who sees both partial signatures can solve for the signer's private key using simple algebra. This is a fundamental property of Schnorr-based protocols, not a bug in MuSig2. BIP327 implementations must generate cryptographically fresh nonces for every signing session and never persist nonces across sessions.

Does MuSig2 work with hardware wallets?

Yes. Ledger added MuSig2 support to their Bitcoin app in version 2.4.0 (April 2025). The main challenge for hardware wallets is that MuSig2 requires two-round interaction: the device must store nonce state between rounds without risking nonce reuse if a session is interrupted. Stateless signing (where the device doesn't need to remember nonces between rounds) is an area of active research.

How much do MuSig2 transactions save on fees?

A Taproot key-path spend (MuSig2 or single-key) uses approximately 57.5 vBytes per input, compared to about 104 vBytes for a P2WSH 2-of-3 ECDSA multisig input. That is roughly 45% fewer vBytes per input. BitGo reported approximately 30% total transaction fee savings in their production deployment. Savings increase with more signers: a 5-of-5 ECDSA multisig is far larger than the equivalent MuSig2 spend, which remains the same 57.5 vBytes regardless of signer count.

Can MuSig2 be combined with Taproot script paths?

Yes. A common pattern is to use MuSig2 for the key-path (the cooperative case where all parties agree) and include script-path leaves for fallback conditions such as timelocks or alternative signing policies. This is the approach used in LND's Simple Taproot Channels, where the MuSig2 key-path handles cooperative closes and the script tree contains HTLC and commitment scripts for force-close scenarios. See Taproot use cases for more examples.

Is FROST ready for production use on Bitcoin?

Not yet. As of mid-2026, FROST on Bitcoin lacks a finalized BIP (the signing BIP is at version 0.3.5 and the DKG BIP is still in development). No production wallet has deployed FROST on Bitcoin mainnet. The Zcash Foundation's Rust implementation includes a Taproot-compatible crate, and Blockchain Commons has released educational tooling, but the ecosystem needs finalized specifications and audited wallet integrations before FROST is production-ready for Bitcoin key management.

This reference is for informational purposes only and does not constitute financial or security advice. Cryptographic protocol specifications evolve: always consult the latest BIP drafts and implementation documentation before building systems that depend on MuSig2 or FROST. Verify current implementation status directly with library maintainers.