MuSig2 Has Arrived in Version 2.4.0 of Ledger Bitcoin App

Bitcoin’s latest multisignature evolution – MuSig2 – has arrived in version 2.4.0 of Ledger Bitcoin app. Completing a path that started with Taproot support, continued with multisig and PSBT support, and then with miniscript. MuSig2 demonstrates Ledger’s position at the bleeding edge of bitcoin self custody technologies and our commitment to enhancing usability without compromising security.

MuSig2 brings improved privacy and reduced fees for use cases like:

Inheritance, account recovery, governance
Cosigners

This post compares MuSig2 with the alternatives, and discusses the applications and the implementation challenges.

Multisig & Miniscript

MultisigMiniscript Supported since Bitcoin’s inception by Satoshi Nakamoto, multisig refers to a mechanism where multiple signatures for multiple keys are required to authorize a transaction using the OP_CHECKMULTISIG opcode to add an extra layer of protection and eliminate single points of failure.

Instead of relying on one private key, multisig wallets utilize an M-of-N scheme — such as 2-of-3 — meaning at least two out of three specified signatures must approve any transfer.

This approach can be used to enhance operational security, enable shared ownership of funds, create escrow services, or just reduce individual key-management risks.

Multisig can facilitate advanced wallet setups in combination with timelocks – spending conditions that are only active after a certain time. This approach is gaining popularity thanks to the growing support of miniscript.

Taproot & Schnorr Signatures

Taproot Taproot, active on Bitcoin since November 2021, was the last upgrade to the Bitcoin protocol. It included implementation of Schnorr signatures along with other improvements aimed at enhancing the network’s privacy, scalability, and smart contract capabilities.

By enabling the combination of multiple keys and signatures into a single one, Taproot reduced the data load of complex transactions, leading to lower transaction fees and increased throughput.

Furthermore, Taproot enhanced the functionality of smart contracts on Bitcoin, allowing for more complex and efficient scripting possibilities without compromising security or privacy. The improvements are especially notable when using more complicated spending conditions, like the ones enabled by miniscript.

Click for more technical details

The Taproot soft-fork introduced a new kind of address, and corresponding output, called P2TR (Pay-to-Taproot). In such addresses, a single, valid Schnorr public key (called the taproot public key) contains a commitment to:

A valid public key, called the internal key.
The Merkle root of the taproot Script tree.

BIP-341 defines two ways of spending a P2TR UTXO: the keypath spend, which requires producing a valid signature for the taproot public key; or the script spend, which allows to reveal one of the Scripts in the Merkle tree, and then satisfy its spending conditions – much like it was possible for older UTXO types, like legacy or segwit Scripts.

One of the most attractive properties of Schnorr signatures is that they enable schemes supporting key aggregation: multiple public keys can be ‘merged’ together, producing a single aggregate public key. The owners of those keys can cooperate to produce a valid signature for the aggregate public key. The most well-known cryptographic schemes allowing this are MuSig2 and FROST.

As the key path spending in Taproot is limited to a valid Schnorr public key, MuSig2 and FROST greatly extend the possibilities of such transactions.

MuSig2 – Enabling Key Aggregation

KeyAggregation Creating an N-of-N multisig output using the OP_CHECKMULTISIG opcode requires publishing on the blockchain N public keys when creating the output (or when spending it if the multisig is wrapped in a P2SH or P2WSH script) and N ECDSA signatures when spending it. This is a huge waste of block space, incurring transaction fees growing linearly with N. This is also a loss of privacy as it reveals the number of parties owning the output. Fortunately, cryptography can help do better.

A multi-signature scheme is a cryptographic protocol which allows a group of users to collectively sign some message with a single constant-size signature rather than having each signer produce its own independent signature. Until the development of the MuSig family, the prominent scheme for this was the Bellare-Neven scheme, proposed in 2006. However, checking a Bellare-Neven multi-signature still requires the public keys of all signers. If we were to use this scheme to create Bitcoin multisig outputs, this would require publishing a single signature (good!) but still as many public keys as there are parties controlling the output (bad!).

MuSig solved this problem by enabling key aggregation, meaning a single public key has to be recorded on the blockchain, independently of the number of signers. For this, each signer generates its own key pair and sends the public key to other parties. Once all public keys have been collected (by some designated signer or a coordinator), the aggregate public key can be computed by combining all signers’ public keys linearly with coefficients computed through some hash function.

The resulting aggregate key looks just like a normal (Schnorr) public key and signers can collectively compute a valid signature for this public key. As a result, one can create a multisig output with just one public key and validate a transaction spending it with one signature, independently of the number of parties involved! Moreover, verification works exactly as for a standard Schnorr signature, meaning someone examining a MuSig2 output has no way to distinguish it from a normal, boring single-party output: privacy comes as a bonus on top of space savings.

These amazing properties certainly come with drawbacks. The most important is that MuSig1 and MuSig2 are interactive protocols requiring several communication rounds between signers. In contrast, vanilla multisigs based on OP_CHECKMULTISIG are non-interactive: signers receive the transaction and return the signature.

MuSig1, proposed in 2018, required three rounds of communication, rendering it difficult to use in practice. Its successor, MuSig2, proposed in 2021, improves the situation by requiring only two rounds of communication. Moreover, the first round, which merely consists of ephemeral nonces (concretely, random elliptic curve points), can be preprocessed before knowing the message to be signed. This means that MuSig2 is “almost” non-interactive and the user experience is very similar to the one provided by OP_CHECKMULTISIG.

The Benefits of MuSig2 vs. FROST

Unlike OP_CHECKMULTISIG wallets which support M-of-N policies where M is an arbitrary threshold of signers between 1 and the number N of involved parties, MuSig2 is limited to N-of-N wallets.

In order to fully replicate the exact functionality of OP_CHECKMULTISIG, one must resort to a threshold signature scheme, which is very much like a multi-signature scheme supporting key aggregation such as MuSig2, except it additionally allows to set an arbitrary threshold M of signers required to produce a signature. The prominent scheme for this (compatible with Schnorr signatures) is called FROST. So one might wonder: why use MuSig2 if FROST allows more flexibility when creating a multisig output?

The reason is that FROST comes with an additional layer of complexity: distributed key generation. FROST relies on Shamir secret sharing, a technique to share a secret among N parties such that M parties can reconstruct the secret, but M-1 parties cannot get any information about the secret.

In order to securely share the secret signing key (without relying on a trusted third party), the signers must run a complex key distribution protocol. Although such protocols have long been studied in the cryptography literature, there is no off-the-shelf implementation available or even a well-accepted standard (although this might soon be the case thanks to the so-called ChillDKG proposal).

In contrast, distributed key generation for MuSig2 is childishly simple: each signer generates its own key pair as usual and shares the public key with his co-signers; public keys are then aggregated by linear combination. This does not require any interaction nor any complex cryptographic tool.

Standards

The primary reference is BIP-327, which goes into every detail of the protocol, precisely specifying all the algorithms required in MuSig2. We implemented MuSig2 to the letter as much as possible, with a C implementation based on the Ledger Secure SDK for cryptographic operations.

Besides BIP-327, various other standards had to be created or updated for MuSig2 support:

BIP-328: Derivation Scheme for MuSig2 Aggregate Keys.
BIP-373: MuSig2 PSBT Fields.
BIP-388: Wallet Policies for Descriptor Wallets.
BIP-390: musig() Descriptor Key Expression

The implementation in the Ledger Bitcoin app is fully compatible with wallet policies containing musig() expressions as defined in BIP-388, and adheres to the standards for aggregate key derivations and MuSig2 PSBT fields.

Challenges for Signing Devices

While BIP-327 goes into great length into specifying every aspect of the MuSig2 signing protocol, real-world implementations on embedded devices face additional challenges.

Round 1 of MuSig2 requires maintaining some state (a random number) that needs to be available until Round 2. The protocol is also secure in the case of parallel signing sessions (meaning: multiple independent executions of Round 1 are happening before completing their respective Round 2s). It is critical that the randomness used in each session is not predictable, not leaked, and not reused in any other session.

Parallel sessions are crucial for bitcoin transactions, as the typical spend from a wallet account might contain many UTXOs as inputs; in the context of MuSig2, each of them is its own independent signing session.

The secure element of Ledger devices features a True Random Number Generator that can be used to create cryptographically strong random numbers. Moreover, it contains a secure NVRAM that can store the randomness and keep it secret while a session is in progress.

An innovation in the implementation of the Ledger Bitcoin app is the definition of PSBT-level signing sessions. From the point of view of the user (and their software wallet), signing a transaction is usually an atomic act: one does not sign just one or a few inputs of the transaction—it signs all of them. Therefore, at the application level, it is more natural to think of a signing session in terms of the transaction being signed, even if that implies multiple parallel MuSig2 signing sessions in terms of BIP-327.

The main challenge comes from the fact that the amount of NVRAM is very limited. A direct implementation of the BIP-327 would require storing the randomness required for each of those signing sessions (typically, 32 bytes). This implies reserving in the NVRAM an amount of storage needed for the maximum supported number of parallel signing sessions that could happen at the same time. But this is almost unbounded for an individual transaction: the Ledger bitcoin app currently supports transactions with up to 512 inputs, and one might have multiple musig() expressions in a single wallet policy; finally, one might want to sign multiple transactions at once. This quickly gets out of hand. Moreover, reading and writing frequently to the NVRAM (which is a flash memory) could shorten the lifetime of the device.

In order to address this, the Ledger Bitcoin app defines a single random rand_root for the entire transaction. Then, a family of pseudo-random numbers is defined as:

rand_i,j= SHA256(rand_root || i || j)

where

i is the index of the input within the transaction.
j is the index of the key expression containing musig() in the wallet policy.

This synthetic randomness never goes out of the Secure Element. Therefore, from the point of view of a BIP-327 signing session, it is as good as true randomness.

This enables the implementation of MuSig2 support without annoying, artificial limitations. As of version 2.4.0, the Bitcoin app supports signing up to 8 simultaneous, independent transactions containing MuSig2 key expressions, with no limitation on the number of inputs.

MuSig2 Use Cases

MS2usecases While it does not enable many fundamentally new constructions (as Script-based multisigs can already encode the same kind of spending conditions), MuSig2 is the cherry on top of the taproot cake. It allows to take full advantage of the design of taproot, especially in the more complex scenarios enabled by miniscript.

Better Privacy & Lower Fees

Miniscript wallets like Liana combine a default spending path (that can be single signature, multisig, etc.) with one or more recovery paths that only become available after a timeout. This allows use cases like inheritance, decaying or expanding multisigs, but also, more simply: recovery giving you an escape hatch if disaster happened and you lost access to your primary spending path.

The primary path, very often, is a simple spending policy: maybe single-signature, or maybe a simple multisignature like 2-of-2 or 3-of-3.

In all such cases, instead of using a Script, it is now possible to use MuSig2. This improves privacy, as transactions spending a MuSig2 keypath are indistinguishable from any other keypath spend. It also reduces the on-chain cost, resulting in significantly smaller fees for the user.

Note: for more complex scenarios where the primary spending path is a M-of-N threshold scheme, MuSig2 is not enough to be used in the keypath. FROST could do that, but the road to standardization and deployment is still long. However, any M-of-N threshold scheme can be decomposed into many M-of-M multisignature spending conditions. For example, a 2-of-3 could be simulated with 3 separate 2-of-2 spending conditions, each using MuSig2. One of them (the most likely to be used) can be conveniently put in the taproot keypath, while the other two will be in the script spending paths.

The Invisible Cosigner

One of the yet-underexplored applications of more complex setups is the addition of a mandatory cosigner for a spending policy.

Cosigners are amazing because they are easy to program, and they can sign in the background, without user interaction. Therefore, adding a mandatory cosigner can add security properties without making the user experience any worse or more complicated.

However, relying too much brings new risks. Since the cosigner is always online and ready to sign, it should be considered a hot key in your setup. And hot keys must be handled with care!

InvisibleCosigner We discussed in this post why some natural-looking wallet setups could actually be dangerous, allowing certain attacks if your computer were to be compromised at the time the new wallet account was being set up. However, timelocked recovery paths without the cosigner (while adding the cosigner in the primary spending path) eliminate those risks.

The attractiveness of a cosigner comes from its programmability and ease of use: it enables spending policies that cannot be enforced in Script (for example: “lock the account while I’m on vacation”, or “don’t allow spending more than 0.01 ₿ per day”, or “don’t authorize transactions during weekends”).

While these things are also possible with normal, Script-based multisig schemes, MuSig2 brings a huge improvement: adding the cosigner comes for free. It’s totally invisible to people that do not know your wallet policy, has no on-chain footprint, and it can be implemented so that signing happens entirely in software, with no change to the user experience that you would have without the cosigner. Therefore, we expect that MuSig2 will be very compelling to build wallets that use a cosigning service in order to provide additional security properties, without making life harder for the user. Good technology just works.

MuSig2 – A Valuable Addition to the Bitcoin Builder’s Toolkit

Since the get-go, Ledger’s new Bitcoin app has been constantly innovating and supporting the most modern and advanced standards.

We are proud to add MuSig2 to the Bitcoin builder’s toolkit, enhancing privacy and reducing fees and are confident that the community will embrace the opportunities MuSig2 presents to create new exciting use cases that will continue to push Bitcoin adoption and innovation.

Co-authored by Salvatore Ingala (Bitcoin Engineer) and Yannick Seurin (Cryptographer)