MuSig2: Simple Two-Round Schnorr Multisignatures
Tags: Research, Bitcoin, Cryptography, Bitcoin Protocol, Multisig

This raises the question of which scheme to use in a given application. The table above demonstrates that there is no reason to prefer MuSig1 over MuSig2. In practice, we expect that most applications will choose MuSig2 over MuSig-DN because simplicity is a dominant factor for adoption. This is especially true when creating interoperable implementations since all signers must agree on using the same protocol. Moreover, support for non-interactive signing increases usability significantly.

On the other hand, if open signing sessions need to be stored on a persistent medium, the statelessness property of MuSig-DN is beneficial. To demonstrate the risk with MuSig2 in that scenario, imagine we perform the following sequence of events:

Start a MuSig2 signing session. Save the session to a hard drive. Perform a hard drive backup. Finish the signing session. Restore the backup. Complete the session again.

The result is that we create two signatures with the same nonce, which can be used to steal our secret key. Therefore, implementers of MuSig2 must be careful and make sure that the above scenario can not occur. In contrast, MuSig-DN is robust against this attack.

The challenge of constructing two-round multi-signatures

Constructing a simple Schnorr multisignature scheme that needs only two rounds and is still secure under concurrent sessions (i.e., if some signer is involved in multiple signing sessions simultaneously) was an unsolved research problem. All previous attempts (including an early version of the MuSig1 paper) suffered from a subtle attack discovered by Drijvers et al. in which an attacker opens many sessions with a victim signer and is able to obtain a signature on a message that the victim did not intend to sign.

Let us quickly look at what makes MuSig2 secure under concurrent sessions. Where in MuSig1, each signer i creates a single nonce, in MuSig2, each signer creates two nonces R_i,1, R_i,2 , sends them to the other signers in the first round and effectively uses a random linear combination R_i = R_i,1 + b*R_i,2 of those nonces in lieu of the former single nonce R_i . The coefficient b is the output of a hash function applied to all signers’ nonces, the aggregated public key, and the message. As in MuSig1, the aggregate nonce is then R = R_1 + … + R_n . If any signer changes any of their nonces, every other signer will use a different, random linear combination of their two nonces. This prevents the attacks that were discovered for other two-round multisignature schemes. You can find all the nitty-gritty details in our paper.

Next steps

We’re eager to replace the MuSig1 implementation in the secp256k1-zkp library with MuSig2, which will be simpler and, most importantly, easier to use. With MuSig2 in the toolbox, a few protocols will benefit substantially, such as “scriptless script Lightning” and threshold signatures. If the Bitcoin community chooses to adopt the Taproot softfork, MuSig2 is applicable to a range of Blockstream’s products, such as Blockstream Green and c-lightning, as well as to the Liquid peg mechanism. Indeed, the Liquid Network may activate Taproot before Bitcoin does, letting us use MuSig2 in production even earlier!