Partnered With:

Understanding Bitcoin's New Signature Scheme MuSig2

Read this article in 11 Minutes

Blockstream researchers and Yannick Seurin, a cryptographer at the French National Cyber Security Agency (ANSSI), jointly designed a new scheme called MuSig2

Original title: "Popular Science | An article to understand Bitcoin's new signature scheme MuSig2"

Original source: Free and Easy

With Bit The update of Taproot is getting closer and closer, and community members have considerable interest in the MuSig multi-signature scheme. interest, MuSig allows a group to collectively manage some bitcoins and create a signature to authorize payments. Thanks to MuSig's innovative key aggregation feature, this signature is a regular Schnorr signature that can be processed by the Bitcoin network once Taproot is activated. When used to create multi-signature wallets, MuSig reduces transaction fees and increases privacy compared to the traditional way of n-of-n multi-signatures using the CHECKMULTISIG opcode, which requires n on the blockchain public keys and n ECDSA signatures.

In 2018, Blockstream Corporation released the first version of the MuSig scheme, which we will call MuSig1, as we will discuss below, due to the signature Deploying MuSig1 in practice can be difficult because multiple rounds of communication are required between them. In order to improve MuSig1 and make the signature process easier, Blockstream researchers and Yannick Seurin, a cryptographer from the French National Cyber Security Agency (ANSSI), jointly designed the A new scheme for MuSig2, which requires only two rounds of communication, and this paper is currently undergoing peer review.

This article will briefly introduce the differences between MuSig2 and the previous version of MuSig1, the original author is Jonas Nick and Tim Ruffing.

Interactive problem with MuSig1

< br>

Compared to CHECKMULTISIG-based wallets, the biggest disadvantage of MuSig1 is that it requires interaction between signers, more precisely, three rounds of communication are required to create a signature, and each round of communication requires Consists of messages passed back and forth. The figure below shows the interaction process of two signers. You can imagine one signer using a desktop wallet and another signer using the Blockstream Green cosigner, or signers sharing a Lightning channel that they are trying to close.

In contrast, wallets using CHECKMULTISIG only One round of communication is required: they receive a transaction and return a signature. For example, if payments are forwarded in the Lightning Network using MuSig1, privacy will be improved, but payments will take significantly longer. This problem is exacerbated as communication latency increases. The MuSig1 signature device, stored in a secure safe, requires two visits by its owner to create a signature.

MuSig2 allows non-interactive signatures

< /p>

The newly proposed MuSig2 multi-signature scheme aims to be the successor of MuSig1, which provides the same functions and security as MuSig1, but can eliminate almost all interactions between signers. With MuSig2, signers only need two rounds of communication to create a signature, and critically, one of those rounds can be preprocessed before the signers know the message they want to sign. Once a message needs to be signed, such as a Bitcoin transaction, the process is the same as today's CHECKMULTISIG-based wallets: transfer the transaction to the signer, and receive a signature. Overall, MuSig2 retains the simplicity and efficiency of MuSig1, adding only a small amount of extra computation.

MuSig family

A few weeks ago, research The authors discussed MuSig -DN, which is a two-round communication protocol using zero-knowledge proof, which is much more complicated than MuSig2. The advantage of MuSig-DN is that it supports deterministic nonces, which avoids the need to keep state between signing sessions and rounds (i.e. stateless).

This raises the question of which scheme to use in a given application. The above table shows that we have no reason to choose MuSig1, but should choose MuSig2. In fact, we expect most applications to choose MuSig2 over MuSig-DN, since simplicity is a major factor for adoption. This is especially true when creating interoperable implementations, since all signers must agree to use the same protocol. Additionally, support for non-interactive signing significantly improves usability.

On the other hand, if the signing session needs to be stored on a persistent medium, then the stateless property of the MuSig-DN scheme is beneficial. To demonstrate the risks of MuSig2 in this case, suppose we execute the following sequence of events:

Start a MuSig2 signing session;

Save the session to a hard drive;

Perform a hard drive backup;

Complete signing session;

Restore backup;

again Finishing the session;

As a result, we create two signatures with the same nonce, which can be used to steal our key. Therefore, implementors of MuSig2 must take care to ensure that the above does not happen. In contrast, the MuSig-DN scheme can prevent this kind of attack.

Construct a two-round multi-signature challenge

Construct a simple Schnorr multi-signature schemes that communicate in two rounds and remain secure under concurrent sessions (i.e., if a signer participates in multiple signing sessions at the same time) is an open research problem. All previous attempts (including earlier versions of the MuSig1 paper) suffer from a clever attack discovered by Drijvers et al. In this case, the attacker opens many sessions with the victim signer and is able to obtain signatures for messages that the victim did not intend to sign.

Let's take a quick look at what makes MuSig2 safe from concurrent sessions. Among them, in MuSig1, each signer i creates a nonce, while in MuSig2, each signer creates two nonces R_i,1 and R_i,2, which are sent to other signers in the first round of communication , and effectively use a random linear combination of these nonces R_i = R_i,1 + b*R_i,2, instead of the previous separate nonce R_i. Whereas the coefficient b is the output of a hash function applied to all signers nonces, aggregated public keys, and messages. In MuSig1, the aggregated nonce is 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 attacks that have been discovered against other two-round multi-signature schemes. All details you can find in the MuSig2 paper.

About the next step

Currently blockstream hopes to use MuSig2 to replace the MuSig1 implementation in the secp256k1zkp library, It will be simpler and, more importantly, easier to use. According to the developers, using MuSig2 in the toolbox, some protocols will benefit from it, such as "scriptless scripting Lightning Network" and threshold signatures. If the Bitcoin community chooses to adopt the Taproot soft fork, MuSig2 will apply to a series of Blockstream products, such as Blockstream Green and c-lightning, and it will also apply to the Liquid peg mechanism.