musig: tracking issue - Githubissues

About MuSig

For multi-signature accounts and multi-party contracts we need to implement a n-of-n MuSig protocol (overview, paper).

The verification construction is very similar to the aggregated transaction signature except the key aggregation happens offline — the verifier is exposed only to the single pubkey.

The proving construction is a 3-round MuSig procedure (see the MuSig paper).

We'll also need to extend the ZkVM witness types and Prover API to handle the multi-party signing: we'd need to produce verifiable "signing instructions" that every co-signer can check before computing their part of the signature. It's not clear yet how that should be structured - this remains to be designed.

Checklist

[x] Multi-party API for plain single-message MuSig. PR: #190
[x] implement counterparty state machines, update error type. PR: https://github.com/interstellar/slingshot/pull/229
[x] Pass &mut Transcript to the signing parties. PR: #245
[x] Single-signer API on top of multi-signer PR: #237
[x] Make Musig its separate crate: https://github.com/interstellar/slingshot/pull/253
[ ] ZkVM uses Musig crate (convert from MusigError, MusigPointOp types)
[ ] Multi-message verification API. design doc: https://github.com/interstellar/slingshot/pull/260
[ ] Recursive API to nest musig aggregation as participants in a higher-level musig: #236
[ ] Scalar-adjusted API, so we can have aggregate(n-of-n) + constant for predicate tree usage when n-of-n is inside the left L branch of a disjunction and the constant is an adjustment factor hash(L,R). #234
[ ] Multi-message API for use with signtx mitigating the Russel's attack. #176
[ ] Integrate Multikey with Predicate Tree: #235
[ ] Plug the correct multi-message API for ZkVM's signtx: #146.
[ ] Design the framework for signing rules for use with signtx: #146.
[x] Move MuSig into its own crate: #239.
[x] Defer verification of signatures: #243

FAQ

What's the role of Merlin transcripts?

MuSig can be specified more cleanly with transcripts rather than with nested hash constructions: e.g. instead of making a delinearization factor as H(my key, H(all keys)) you'd just commit all pubkeys into a transcript, then squeeze all factors one by one from it. Also, no need to specify message hashing and padding - just have the user prepare the signature transcript however they please and then do the schnorr proof with it w/o worrying about the message.

How do we do 2-of-3 and other thresholds?

Via predicate tree: happy path would be the most-expected 2-of-2 (Alice+Bob), while other combinations (Alice+Carol, Bob+Carol) tucked into deeper branches. This does not scale well to large number of participants, but works fine for typically small sizes.

Why not a threshold scheme?

Threshold signatures (m-of-n, m ≤ n) use a very similar cryptographic construction outlined in MuSig paper, yet have two important practical differences:

The secret keys have to be interactively created. N-of-N aggregation allows every party to generate or even reuse their existing keys (e.g. derived from a Keytree #87) w/o having to make a multi-round protocol to compute some synthetic keys and have them stored.
Threshold signatures are more compact than a merkle tree of combinations, but not accountable: you can never learn who were exact parties that signed off the particular message. For some protocols it's important to know whether "cold storage key" or "escrow agent" was involved or not. Combining n-of-n keys with the predicate tree allows seeing who actually signed, while threshold signatures erase this information. Note: accountability is available only to the parties in-the-know, for the rest of the network all the keys look random.

We'd eventually need threshold scheme too, especially for large thresholds or for cases where accountability is not necessary and we only need redundancy.

stellar / slingshot

musig: tracking issue #92

About MuSig

Checklist

FAQ

References