MuSig
MuSig is a family of interactive multi-signature protocols that aggregate several public keys into one and produce a single BIP340 Schnorr-compatible signature for that aggregate. On Bitcoin the result can look like an ordinary single-key Taproot key-path spend. The Bitcoin-relevant construction is MuSig2, standardized in BIP327. It is an n-of-n scheme: every listed key must participate. Threshold k-of-n signing is a different design family (for example FROST), not MuSig2.
Script-based n-of-n multisignature reveals the number of keys and needs one signature per key. Schnorr linearity lets keys be aggregated so one joint signature covers the set. The original MuSig scheme (often called MuSig1) needed three communication rounds. MuSig2, published by Jonas Nick, Tim Ruffing, and collaborators, reduces signing to two rounds. BIP327 standardizes encodings, nonce generation, BIP32 and Taproot tweaks, and partial-signature checks so independent wallets can cosign the same Taproot key-path spend.
Key aggregation
BIP327 defines a deterministic KeyAgg algorithm over an ordered list of plain or x-only public keys. Coefficients bind each key into the aggregate so that a rogue-key attack cannot substitute an adversary-controlled aggregate. Optional BIP32 derivation and BIP341 Taproot tweaks are applied in the order the BIP specifies. The aggregate public key is what wallets put in a tr() descriptor or compare against a PSBT output.
Because aggregation is n-of-n, removing or reordering a participant changes the aggregate key. Backup and recovery procedures must store the full participant list and tweak schedule, not only one extended private key.
Signing rounds
Each signer contributes a fresh public nonce, then a partial signature. Partial signatures combine into one 64-byte BIP340 signature that verifies under BIP340 rules for the aggregate key. Reusing a secret nonce across sessions can leak the key. An optional untrusted aggregator can collect nonces and partials to cut communication cost. It may abort but cannot forge a valid aggregate signature alone.
Session transcripts must bind the aggregate key, the message, and each participant's nonce so a partial signature cannot be replayed in another session. Signers should verify every peer nonce and every partial signature against the BIP327 equations before releasing their own second-round share.
Wallet notes
Wallets that cosign a MuSig2 Taproot key must agree on key aggregation order, tweaks, and nonce handling before signing begins. BIP327 defines the algorithms and encodings so independently written implementations can produce matching aggregate keys and compatible partial signatures. Lightning and other multiparty protocols may prefer MuSig2 key aggregation where every participant is expected to be online for n-of-n authorization, while threshold custody more often looks to FROST.
Hardware signers that implement BIP327 need the key aggregation coefficients and Taproot tweak in the PSBT or an equivalent secure channel. Mismatched participant lists produce a different aggregate key and an on-chain script that nobody can satisfy together. Test vectors in BIP327 are the usual interoperability check between libraries. Wallets should refuse to sign if the claimed aggregate key does not equal the MuSig2 key aggregation of the advertised participant keys and tweaks.
On-chain, a MuSig2 key-path spend is indistinguishable from any other BIP340 Taproot key-path spend. Script-path alternatives remain available if the Taproot tree commits to fallback policies.