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 permits a bunch of contributors to collectively produce a single Schnorr signature that’s legitimate for an combination of their public keys. Verifiers don’t must know or care that the signature was constructed by means 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 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) may be became IAS schemes like this, there are less complicated algorithms like BN06 that additionally assist this.
This distinction is related for the way these applied sciences can be utilized in Bitcoin:
-
Multi-signatures can be utilized as a less expensive, extra compact, and extra personal 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 contributors) 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 change into a part of its protocol or consensus guidelines. It’s simply one thing any group of wallets that wish to interact in multisig-like management of funds can select to make use of, with out anybody else needing to bear in mind. -
The IAS variant is doubtlessly helpful for cross-input aggregation (CISA): the concept that a whole transaction (not only a single enter of a transaction) would solely want a single signature, created collectively by all contributors whose cash are spent by the transaction. That is sometimes only a single occasion, 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 set, it’s finished when spending.
- The set contributors will not be identified earlier than spending time (e.g., in a CoinJoin they’re selected the fly).
- This requires integration into Bitcoin’s consensus guidelines. There is no such thing as a approach at the moment 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 convey this distinction up as a result of primarily based 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 utility I am conscious of that really wants one thing like this. Utilizing MuSig as a alternative for multisig may be finished by anybody at any time, with out anybody’s permission. We would not even be capable to inform if somebody have been to be utilizing MuSig1 at the moment on Bitcoin.
Lastly, whereas the “P” in BIP means “proposal”, BIPs are actually simply the title of the paperwork, and course of round these paperwork, through which 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’s not 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 okay 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 often known as threshold signatures. There’s work as properly on Bitcoin-compatible threshold signatures, such a FROST.
As to your questions:
- Sharing ti, Ri, and si: How do contributors ship their commitments (ti), share their Ri values, and change partial signatures (si)? What does this course of appear like in observe? Is there a regular, asynchronous, and user-friendly method to handle this in software program? Or do contributors must manually compute their si, sum them, and share the outcomes backwards and forwards?
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 contributors can then change PSBT recordsdata with one another.
Past that, count on that MuSig2 will probably be built-in into extra ad-hoc protocols.
Events can combination the partial nonces obtained from different events themselves, or have one coordinator try this for them. A dishonest coordinator can solely end in an invalid signature; they can not 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 instances? Is the verification finished 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’s not obtainable inside P2SH. Since they’re simply signatures, no script is required. Anyplace the place one would wish to use a signature to spend an output, MuSig2 multisig could possibly be used as a substitute of the conventional (single occasion) BIP340 signing. The verifier is all the time simply Bitcoin nodes that validate blocks and transactions, however once more, they won’t even bear in mind that MuSig2 is concerned. To them, it is only a regular key, and a traditional signature.
And relating to 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 move?
One of many events, or a coordinator, will combination the partial signatures and assemble the complete signature, which may then be positioned within the spending transaction, which is able to 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 dearth of commitments?
In MuSig1, with out the primary nonce-commitment part, replay assaults are potential the place contributors can be taught the personal key of different contributors. In MuSig2, this part doesn’t exist anymore.
