BIP-327 (MuSig2)

What Is BIP-327 (MuSig2)?

BIP-327 is a Bitcoin Improvement Proposal that specifies MuSig2, a multi-signature scheme for creating aggregate Schnorr signatures compatible with BIP-340. Authored by Jonas Nick, Tim Ruffing, and Elliott Jin, it was merged into the Bitcoin BIPs repository in March 2023. The underlying MuSig2 cryptographic scheme was published at CRYPTO 2021 by Jonas Nick, Tim Ruffing, and Yannick Seurin.

In traditional Bitcoin multisig using Bitcoin Script (OP_CHECKMULTISIG), every public key and every signature must appear on-chain. A 3-of-3 multisig transaction reveals three keys and three signatures, making its structure visible to any blockchain observer. MuSig2 collapses all of this into a single 32-byte aggregate public key and a single 64-byte signature that looks identical to a regular Taproot spend.

This is possible because Schnorr signatures are linear: partial signatures from multiple signers can be summed to produce a valid aggregate signature. ECDSA, the signature scheme used in pre-Taproot Bitcoin, does not have this property, which is why MuSig2 requires the Taproot upgrade activated in November 2021.

How It Works

MuSig2 operates in two distinct phases: key aggregation (a one-time setup) and the two-round signing protocol (repeated per transaction).

Key Aggregation

Before any signing occurs, the participants combine their individual public keys into a single aggregate public key. BIP-327 defines the KeyAgg algorithm for this purpose:

1. Each signer provides their compressed 33-byte public key
2. A key aggregation coefficient is computed for each key using a tagged hash of the complete set of keys
3. The aggregate key is the weighted sum of all individual keys, using these coefficients as weights

Key aggregation is non-interactive: no communication between signers is required beyond sharing public keys. The aggregate key can be used directly as a Taproot internal key, and funds sent to this key can only be spent when all signers cooperate.

Round 1: Nonce Exchange

When the signers want to create a transaction, each signer generates two random secret scalars (k1, k2) and computes their corresponding elliptic curve points. These produce a public nonce (66 bytes: the two nonce points serialized) and a secret nonce (97 bytes: the two scalars plus the signer's public key).

Each signer shares only their public nonce with the other participants. The secret nonce must never be revealed. Once all public nonces are collected, the NonceAgg algorithm combines them by summing the nonce points.

A critical optimization: nonces can be generated and exchanged before the message (transaction) is known. This allows the first round to be preprocessed, reducing the interactive signing to a single round of communication once the transaction is ready.

Round 2: Partial Signature Exchange

With the message and all public nonces available, each signer computes a partial signature using the Sign algorithm. The effective combined nonce R is calculated as:

R = R1 + b * R2

where:
  R1, R2 = aggregated nonce points from NonceAgg
  b = tagged_hash(R1, R2, aggregate_pubkey, message)

Each signer then computes their partial signature:

s_i = (k1_i + b * k2_i + e * a_i * d_i) mod n

where:
  k1_i, k2_i = signer i's secret nonce scalars
  e = Schnorr challenge hash (tagged_hash of R, aggregate_pubkey, message)
  a_i = key aggregation coefficient for signer i
  d_i = signer i's secret key (with parity adjustment)

Signers exchange their partial signatures. The PartialSigAgg algorithm sums all partial signature scalars to produce the final aggregate signature (R, s). This output is a standard BIP-340 Schnorr signature that passes normal verification against the aggregate public key.

Identifiable Aborts

BIP-327 includes PartialSigVerify, which allows verification of individual partial signatures. If a signer submits an invalid partial signature (whether due to a bug or malicious intent), the other participants can identify exactly which signer misbehaved rather than simply detecting that the aggregate signature is invalid.

Why MuSig2 Over MuSig1?

The original MuSig protocol (published in 2018 by Gregory Maxwell, Andrew Poelstra, Yannick Seurin, and Pieter Wuille) required three rounds of communication:

1. Nonce commitment exchange: each signer shares a hash of their nonce
2. Nonce reveal: each signer reveals their actual nonce after seeing all commitments
3. Partial signature exchange

The commitment round was necessary to prevent a rogue-key attack where an adversary could manipulate nonces after seeing honest signers' nonces. Three rounds made MuSig1 impractical for many real-world applications, especially those with high-latency communication.

MuSig2 solves this by using two nonces per signer instead of one. Computing the effective nonce as a random linear combination (R = R1 + b * R2) eliminates the commitment round entirely while maintaining provable security under concurrent signing sessions. Prior to MuSig2, constructing a secure two-round Schnorr multisignature scheme had been an open research problem.

MuSig2 vs. Script-Based Multisig

The differences between MuSig2 and traditional script-based multisig are significant:

BitGo, the first major custodian to deploy MuSig2, reports approximately 47 vBytes savings per input compared to Native SegWit multisig, translating to roughly 30% lower transaction fees. For detailed analysis, see the multisig wallets research article.

Relationship to FROST

FROST (Flexible Round-Optimized Schnorr Threshold signatures) is a related but distinct protocol. While both produce standard Schnorr signatures indistinguishable from single-signer outputs, they solve different problems:

• MuSig2 is n-of-n: every signer must participate in every signing session. It uses simple, non-interactive key aggregation.
• FROST is m-of-n: only a threshold subset of signers is needed. It requires a more complex Distributed Key Generation (DKG) ceremony during setup.

MuSig2 can approximate threshold behavior by pre-computing MuSig2 aggregate keys for every valid signer combination and encoding them in a Taproot script tree. For a 2-of-3 setup, this means three leaf scripts (one per pair). This approach becomes impractical at larger scales: a 5-of-10 setup would require 252 leaf scripts. For such cases, FROST is the better choice. Spark uses FROST for its threshold signing, enabling flexible custody models without the combinatorial explosion.

Use Cases

Taproot Multisig Wallets

MuSig2 enables multisig wallets that look like single-signature wallets on-chain. Custodians like BitGo use MuSig2 for hot wallets, with the aggregate key as the Taproot internal key for the cooperative spending path. If all signers are online and cooperating, the transaction settles through the key path with maximum privacy and minimum fees.

Lightning Network Channels

Lightning channel funding outputs are 2-of-2 multisig: both channel partners must sign to spend. MuSig2 replaces the legacy P2WSH multisig format with a single Taproot key path, making channel opens and cooperative closes indistinguishable from regular payments. LND integrated MuSig2 for experimental Taproot channels starting in 2023.

Collaborative Custody

Any arrangement where multiple parties jointly control funds benefits from MuSig2. Examples include joint accounts, corporate treasury management, and inheritance setups. When combined with PSBTs (using BIP-373 for MuSig2 fields), the signing workflow integrates with existing wallet software including hardware signing devices.

Protocol-Level Signing

Layer 2 protocols and covenant designs use MuSig2 for cooperative operations. For a deeper look at how MuSig2 fits into the broader multisignature landscape, see the MuSig2 multisignatures research article.

Risks and Considerations

Nonce Reuse Is Catastrophic

If a signer ever reuses a secret nonce across two different signing sessions, their private key can be extracted algebraically. This is not a theoretical concern: a malicious co-signer can deliberately trigger this by opening two signing sessions and providing different nonces to the victim in each session, while the victim unknowingly reuses the same nonce.

BIP-327 mandates random nonce generation rather than deterministic nonces. Unlike single-signer Schnorr or ECDSA where deterministic nonces (RFC 6979) are safe, in MuSig2 an adversary can replay protocol messages to force nonce reuse. The single exception is the DeterministicSign variant, which allows exactly one signer (typically a hardware wallet) to generate nonces deterministically after receiving all other signers' nonces.

Interactivity Requirement

Every signing session requires two rounds of communication between all signers. If any signer is offline, the transaction cannot be signed. This contrasts with script-based multisig, where each signer can independently produce their signature. For setups involving cold storage or air-gapped devices, the round-trip requirement adds operational complexity.

The nonce pre-processing optimization (generating nonces before the transaction is ready) helps reduce latency but does not eliminate the need for all signers to be available at signing time.

Security Assumptions

MuSig2 is proven secure under the algebraic one-more discrete logarithm (AOMDL) assumption in the Random Oracle Model combined with the Algebraic Group Model. This is a stronger assumption than the plain discrete logarithm assumption used for single-signer Schnorr signatures. While considered sound by the cryptographic community, it means MuSig2's security proof relies on more assumptions than a standard signature.

n-of-n Limitation

MuSig2 requires all signers to participate. Losing access to any single signer's key means the funds are unspendable through the MuSig2 key path. Practical deployments typically combine MuSig2 with Taproot script paths that provide fallback spending conditions (timelocks, alternative signer sets) to mitigate this risk. For native threshold signing without combinatorial blowup, protocols like FROST are more appropriate.

Ecosystem Adoption

Since its standardization, MuSig2 has seen growing adoption across the Bitcoin ecosystem. BitGo deployed it for Taproot multisig hot wallets. Ledger added MuSig2 support in their Bitcoin app (version 2.4.0). Nunchuk launched a Taproot multisig wallet using MuSig2. The libsecp256k1 library added an optional MuSig2 module in October 2024. On the protocol side, LND uses MuSig2 for Taproot channel funding outputs, and Lightning Loop migrated to MuSig2 by default in 2025.

Complementary BIPs have been proposed to round out the MuSig2 toolchain: BIP-328 for key derivation, BIP-373 for PSBT fields, and BIP-390 for output script descriptors.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.