For all intents and purposes, the MuSig1 scheme is supplanted by the MuSig2 scheme (and the MuSig2* scheme defined in the same paper). MuSig2 only needs 2 rounds of interactions, as opposed to the 3 rounds that MuSig1 needs, at the cost of a small bandwidth and computation increase. As far as I know, no production-ready specification for MuSig1 was ever written, and nobody ever deployed MuSig1 in production.
MuSig1 and MuSig2 are multi-signature schemes, which support key aggregation compatible with Schnorr signatures. This means that it enables a group of participants to jointly produce a single Schnorr signature that is valid for an aggregate of their public keys. Verifiers do not need to know or care that the signature was constructed through MuSig; for all intents and purposes, it is a normal Schnorr signature.
The MuSig1 paper does additionally propose an Interactive Aggregated Signature (IAS) variant of the MuSig1 multi-signature scheme. In this variant, each signer can have their own message to sign, and the result is not compatible with Schnorr signatures (because the verifier needs to know all messages being signed, while Schnorr signatures only have one message). While MuSig1 (and MuSig2) can be turned into IAS schemes like this, there are simpler algorithms like BN06 that also support this.
This distinction is relevant for how these technologies can be used in Bitcoin:
-
Multi-signatures can be used as a cheaper, more compact, and more private replacement for Bitcoin’s traditional
OP_CHECKMULTISIG-based multisig(*) scripts. Instead of publishing all public keys, and all individual signatures to the blockchain at spending time, only the aggregated public key (pre-negotiated between the participants) and the aggregated multi-signature is published. Notably, this does not require integration of the scheme “in” Bitcoin, in the sense that it doesn’t become part of its protocol or consensus rules. It is just something any group of wallets that want to engage in multisig-like control of funds can choose to use, without anyone else needing to be aware. -
The IAS variant is potentially useful for cross-input aggregation (CISA): the idea that an entire transaction (not just a single input of a transaction) would only need a single signature, created jointly by all participants whose coins are spent by the transaction. This is typically just a single party, but may involve multiple parties in the case of CoinJoin, for example. This is distinct from the multi-signature case in multiple ways:
- Each output still has its own public key(s). Instead of doing the key aggregation ahead of time when the address is decided, it is done when spending.
- The set participants may not be known before spending time (e.g., in a CoinJoin they are decided on the fly).
- This requires integration into Bitcoin’s consensus rules. There is no way today for scripts to even observe what other inputs of the same transaction are doing. Enabling the ability to have a single signature for all of them necessarily means changing that.
I bring this distinction up because based on your comments, you seem to be under the impression that MuSig (1 or 2) needs to be integrated “into” Bitcoin, and CISA is the only application I’m aware of that actually needs something like this. Using MuSig as a replacement for multisig can be done by anyone at any time, without anyone’s permission. We wouldn’t even be able to tell if someone were to be using MuSig1 today on Bitcoin.
Lastly, while the “P” in BIP means “proposal”, BIPs are really just the name of the documents, and process around those documents, in which specifications for Bitcoin are published. Some BIPs never make it past the point of being a proposal, but others end up being part of the protocol. In either case, it is not because something is (still) a BIP that it is or isn’t “part of Bitcoin”. This is up to individual software choosing to implement these proposals or not.
(*) Note that “multisig” in Bitcoin context means “k-of-n spending policy” (where k may be less than n), while multi-signatures in the cryptography context means “compact n-of-n signature”, while compact k-of-n signatures are known as threshold signatures. There is work as well on Bitcoin-compatible threshold signatures, such a FROST.
As for your questions:
- Sharing ti, Ri, and si: How do participants send their commitments (ti), share their Ri values, and exchange partial signatures (si)? What does this process look like in practice? Is there a standard, asynchronous, and user-friendly way to manage this in software? Or do participants need to manually compute their si, sum them, and share the results back and forth?
For MuSig2 (itself specified for Bitcoin in BIP327), there is BIP373 which specifies MuSig2-specific fields for the PSBT (partially signed Bitcoin transaction) format. Multisig participants can then exchange PSBT files with each other.
Beyond that, expect that MuSig2 will be integrated into more ad-hoc protocols.
Parties can aggregate the partial nonces received from other parties themselves, or have one coordinator do that for them. A dishonest coordinator can only result in an invalid signature; they can’t cause forgeries or key leaks.
- Verification Process: Who verifies the final signature (Rsum, ssum)? When and how does this verification happen in real-world Bitcoin use cases? Is the verification done via P2SH scripts?
The final signature is (in the case of Bitcoin, using BIP327) is Bitcoin-style Schnorr signature (specified in BIP340). BIP340 signatures can only be used when spending Taproot outputs (specified in BIP341 and BIP342); it is not available inside P2SH. Since they’re just signatures, no script is needed. Any place where one would want to use a signature to spend an output, MuSig2 multisig could be used instead of the normal (single party) BIP340 signing. The verifier is always just Bitcoin nodes that validate blocks and transactions, but again, they will not even be aware that MuSig2 is involved. To them, it’s just a normal key, and a normal signature.
And regarding the initiation of the verification process—does a participant (e.g., one of the multisig signers) who has collected all the Rsum and ssum values create the transaction from the P2SH address? Or am I misunderstanding this flow?
One of the parties, or a coordinator, will aggregate the partial signatures and construct the full signature, which can then be placed in the spending transaction, which will make the spending transaction valid and broadcastable to the network.
- What Happens Without Commitments? What could an adversary do if the commitments (ti) were not part of the protocol? What kind of attacks could occur, and how would they exploit the lack of commitments?
In MuSig1, without the first nonce-commitment phase, replay attacks are possible where participants can learn the private key of other participants. In MuSig2, this phase does not exist anymore.
