MuSig2

Imagine a shared treasury in which both Alice and Bob must approve a payment. A digital signature provides proof of authorization for a payment using a private key, a secret numerical value, without revealing that key. Conventional script-based Multisig can reveal several public keys and signatures in the transaction. With MuSig2, each person keeps their private key and contributes to a joint signature. The network verifies a single result. Savings occur in on-chain storage and verification; the participants still need to coordinate. Jonas Nick, Tim Ruffing and Yannick Seurin introduced the protocol in a paper published in October 2020. [3] [2] [10]

MuSig2 is not, by itself, a 2-of-3 arrangement in which any pair can replace a missing third signer. Every member of its n-of-n group must contribute. An unavailable or unwilling participant can halt cooperation. A wallet is an application or device for receiving and sending bitcoin. A wallet that must remain usable in that situation needs a separately designed spending path or signing mechanism; the name MuSig2 does not provide one automatically. [1] [8]

Before signing, participants construct an aggregate public key. A public key is used to verify signatures and does not need to be kept secret. In the first round they exchange public nonces, one-time contributions used to prepare the signature. In the second they create and exchange partial signatures for the same message and context, then combine them into the final signature. Under the protocol’s conditions, the first round can be prepared before the payment is known. But before creating a partial signature, each participant must check the actual transaction, especially the recipient, amount and fee. Preparation is not approval of an unknown payment, and checking after signing is too late. [1] [3]

With a naive sum, an attacker could choose a public key that exploits the other participants’ keys. MuSig2 therefore uses numerical weights, called coefficients, derived from the key list. KeyAgg also accounts for key order; an application can use KeySort if it wants a consistent ordering. Everyone must use the same list and rules, otherwise they are not computing the same aggregate key. [1] [5]

Here, nonce does not mean a mining counter. It is one-time signing material: pubnonce is shared, while secnonce stays with the signer. A secret nonce must never be reused for another call to Sign. Two partial signatures produced through reuse can expose the private key. Changing the message or repeating an apparently identical payment is not a safe exception. [1] [7]

Correct cryptographic calculations are not enough if an application restores a used secnonce from a backup after restarting, or gives it to two concurrent tasks. Libsecp256k1 invalidates the secret nonce by overwriting it during signing, but a copy outside its control can defeat that protection. State management must prevent reuse during errors, recovery and concurrency. The private signing key may be used repeatedly; the nonce is the one-time component. [7]

A coordinator can relay the exchange, collecting public nonces and partial signatures. Correct use of the protocol does not thereby allow it to sign in place of an honest participant, although it can disrupt the process. Every signer must check what they are signing. Partial-signature verification can help diagnose a problem, but requires the original public contributions and the correct context; an aggregate nonce alone cannot identify the culprit. [1] [7]

The result is a 64-byte BIP340 signature. A Taproot key path is a way to spend in which the network checks a signature against the key recorded in the output without revealing a fallback script. If the default mode is not used, a sighash-type byte follows the signature. It specifies which parts of the transaction the signature commits to, protecting them against changes that would invalidate it. The signature alone does not reveal how many participants there are or their individual keys. MuSig2 does not, however, hide amounts, every connection surrounding the payment or communication between the parties. Nor does it automatically combine signatures for different inputs, which refer to the previously received outputs being spent by the transaction. [5] [6]

Alongside the shared key path, Taproot can include script conditions, such as another combination of keys or a timelock. A timelock makes a particular path available only after a specified time or block height; it does not replace required signatures. A block groups transactions into a batch added to the shared history. Block height is a block’s position in the chain. These conditions must be committed to when the output, a specific amount with spending rules, is created. They cannot be added after a signer is lost. A script path spends through such a script: it reveals the relevant conditions and may cost more. Wallet recovery therefore requires details of the chosen arrangement, not just the individual secret keys. [6] [1] [9]

BIP327 describes the protocol; the library and wallet determine the actual interface, backups and supported workflows. Check the version, test vectors, nonce handling and transaction review. Supporting Schnorr signatures does not by itself give every wallet complete MuSig2 support. Cooperative signing uses existing BIP340 and Taproot rules; using MuSig2 does not itself require a new consensus opcode. [4] [7] [2]