For all intents and functions, the MuSig1 scheme is supplanted by the MuSig2 scheme (and the MuSig2* scheme outlined in the identical paper). MuSig2 solely wants 2 rounds of interactions, versus the three rounds that MuSig1 wants, at the price of a small bandwidth and computation improve. So far as I do know, no production-ready specification for MuSig1 was ever written, and no one ever deployed MuSig1 in manufacturing.
MuSig1 and MuSig2 are multi-signature schemes, which assist key aggregation appropriate with Schnorr signatures. Which means it allows a gaggle of members to collectively produce a single Schnorr signature that’s legitimate for an mixture of their public keys. Verifiers don’t have to know or care that the signature was constructed by way of MuSig; for all intents and functions, it’s a regular Schnorr signature.
The MuSig1 paper does moreover suggest an Interactive Aggregated Signature (IAS) variant of the MuSig1 multi-signature scheme. On this variant, every signer can have their very own message to signal, and the consequence just isn’t appropriate with Schnorr signatures (as a result of the verifier must know all messages being signed, whereas Schnorr signatures solely have one message). Whereas MuSig1 (and MuSig2) might be became IAS schemes like this, there are easier algorithms like BN06 that additionally assist this.
This distinction is related for a way these applied sciences can be utilized in Bitcoin:
-
Multi-signatures can be utilized as a less expensive, extra compact, and extra non-public alternative for Bitcoin’s conventional
OP_CHECKMULTISIG-based multisig(*) scripts. As an alternative of publishing all public keys, and all particular person signatures to the blockchain at spending time, solely the aggregated public key (pre-negotiated between the members) and the aggregated multi-signature is revealed. Notably, this doesn’t require integration of the scheme “in” Bitcoin, within the sense that it does not turn out to be a part of its protocol or consensus guidelines. It’s simply one thing any group of wallets that need to interact in multisig-like management of funds can select to make use of, with out anybody else needing to remember. -
The IAS variant is probably helpful for cross-input aggregation (CISA): the concept a complete transaction (not only a single enter of a transaction) would solely want a single signature, created collectively by all members whose cash are spent by the transaction. That is usually only a single get together, however might contain a number of events within the case of CoinJoin, for instance. That is distinct from the multi-signature case in a number of methods:
- Every output nonetheless has its personal public key(s). As an alternative of doing the important thing aggregation forward of time when the deal with is determined, it’s completed when spending.
- The set members will not be recognized earlier than spending time (e.g., in a CoinJoin they’re selected the fly).
- This requires integration into Bitcoin’s consensus guidelines. There isn’t any means right now for scripts to even observe what different inputs of the identical transaction are doing. Enabling the flexibility to have a single signature for all of them essentially means altering that.
I deliver this distinction up as a result of based mostly in your feedback, you appear to be beneath the impression that MuSig (1 or 2) must be built-in “into” Bitcoin, and CISA is the one software I am conscious of that truly wants one thing like this. Utilizing MuSig as a alternative for multisig might be completed by anybody at any time, with out anybody’s permission. We would not even be capable of inform if somebody have been to be utilizing MuSig1 right now on Bitcoin.
Lastly, whereas the “P” in BIP means “proposal”, BIPs are actually simply the identify of the paperwork, and course of round these paperwork, wherein specs for Bitcoin are revealed. Some BIPs by no means make it previous the purpose of being a proposal, however others find yourself being a part of the protocol. In both case, it isn’t as a result of one thing is (nonetheless) a BIP that it’s or is not “a part of Bitcoin”. That is as much as particular person software program selecting to implement these proposals or not.
(*) Word that “multisig” in Bitcoin context means “k-of-n spending coverage” (the place ok could also be lower than n), whereas multi-signatures within the cryptography context means “compact n-of-n signature”, whereas compact k-of-n signatures are generally known as threshold signatures. There may be work as effectively on Bitcoin-compatible threshold signatures, such a FROST.
As in your questions:
- Sharing ti, Ri, and si: How do members ship their commitments (ti), share their Ri values, and trade partial signatures (si)? What does this course of appear to be in follow? Is there an ordinary, asynchronous, and user-friendly approach to handle this in software program? Or do members have to manually compute their si, sum them, and share the outcomes forwards and backwards?
For MuSig2 (itself specified for Bitcoin in BIP327), there may be BIP373 which specifies MuSig2-specific fields for the PSBT (partially signed Bitcoin transaction) format. Multisig members can then trade PSBT information with one another.
Past that, anticipate that MuSig2 will probably be built-in into extra ad-hoc protocols.
Events can mixture the partial nonces acquired from different events themselves, or have one coordinator try this for them. A dishonest coordinator can solely lead to an invalid signature; they cannot trigger forgeries or key leaks.
- Verification Course of: Who verifies the ultimate signature (Rsum, ssum)? When and the way does this verification occur in real-world Bitcoin use circumstances? Is the verification completed through P2SH scripts?
The ultimate signature is (within the case of Bitcoin, utilizing BIP327) is Bitcoin-style Schnorr signature (laid out in BIP340). BIP340 signatures can solely be used when spending Taproot outputs (laid out in BIP341 and BIP342); it isn’t obtainable inside P2SH. Since they’re simply signatures, no script is required. Anyplace the place one would need to use a signature to spend an output, MuSig2 multisig may very well be used as a substitute of the conventional (single get together) BIP340 signing. The verifier is all the time simply Bitcoin nodes that validate blocks and transactions, however once more, they won’t even remember that MuSig2 is concerned. To them, it is only a regular key, and a standard signature.
And concerning the initiation of the verification course of—does a participant (e.g., one of many multisig signers) who has collected all of the Rsum and ssum values create the transaction from the P2SH deal with? Or am I misunderstanding this circulate?
One of many events, or a coordinator, will mixture the partial signatures and assemble the complete signature, which might then be positioned within the spending transaction, which can make the spending transaction legitimate and broadcastable to the community.
- What Occurs With out Commitments? What might an adversary do if the commitments (ti) weren’t a part of the protocol? What sort of assaults might happen, and the way would they exploit the shortage of commitments?
In MuSig1, with out the primary nonce-commitment section, sensible assaults are attainable the place an attacker begins a number of concurrent signing classes with a sufferer, and succeeds in setting up a solid signature (for a message the attacker chooses, not agreed by the victims). In MuSig2, this section doesn’t exist anymore.