MuSig2

Key aggregation is the whole trick: several participants each hold a private key, and the maths adds their public keys into one aggregate key that none of them controls alone. BIP-327 fixed the scheme at two communication rounds, down from three in the original MuSig. For a shared wallet that means lower fees and no public evidence that the wallet was shared.

How it works

MuSig2 runs in two passes over the group, and only the second pass needs to know what is being signed.

In the first pass every signer generates two secret nonces and publishes the matching pair of points. The coordinator adds those pairs into one combined nonce using a coefficient derived by hashing the whole set. That coefficient is the specific piece of engineering that let the scheme drop a round without reopening the attacks that broke earlier two-round designs.

In the second pass each signer produces a partial signature over the transaction's signature hash and returns a single number. Summed together, those numbers form one 64-byte signature that verifies against the 32-byte aggregate key under ordinary BIP-340 rules. A node validating the block cannot tell how many people were involved, or that anyone was.

Two safety properties are worth naming out loud. Key aggregation applies a per-key coefficient so that a participant cannot craft a public key that cancels everyone else's, the rogue key attack that plain addition of keys permits. And nonces are strictly single use: signing two different messages from the same nonce reveals your private key outright, which is why correct implementations erase the secret nonce the moment it is consumed and refuse a second signature from the same session.

Where you see it

MuSig2 sits behind a Taproot key path spend, so what you actually see is a bc1p address that behaves like any other.

The size argument is concrete. A Taproot key path input costs 57.5 vbytes whether one person signed it or five did, while a two-of-three witness script spend has to reveal three public keys and two signatures and comes in at well over twice that. Taproot outputs became spendable at block 709,632 on November 14, 2021, so the capability has been sitting on the chain for years and the bottleneck has been wallet software.

BIP-373 supplies the plumbing, adding PSBT fields for public nonces, participant keys and partial signatures so a hardware device can join a signing session without every vendor inventing a message format. Adoption in consumer wallets is still thin. The most concrete deployment is the simple taproot channels work in Lightning, where the two peers fund the channel into a single MuSig2 output.

MuSig2 vs multisig

MuSig2 is all-of-n by construction; classic multisig can be any threshold you like.

That difference decides whether it belongs anywhere near your savings. A script based two-of-three keeps working when one key is lost, because the script names three keys and asks for two of them. An aggregate key needs every participant present, and a signer who disappears takes the coins with them unless the same address also commits to a script path holding a recovery branch. Genuine thresholds under one aggregated key need a different protocol, such as FROST, which is not what BIP-327 specifies.

The second trade is deliberate. Script multisig is auditable by anyone with a block explorer, and MuSig2 is not, which is a privacy gain for a household and an obstacle for a treasurer who has to demonstrate that a payment required two officers.