MultiSig via MuSig

[JeremyRubin]

I'm proposing that we add an ecosystem proposal to support MuSig (or similar construction) for the purpose of having a single account key which requires signatures from multiple signers.

This is highly useful for constructing more complex threshold signature schemes and for the performance of state channels with multiple parties.

Furthermore, adding a standardized MuSig construction paves the way for doing key-aggregation within transactions to reduce the number of signatures needed for any transaction to one. (Because of how Stellar works, we do need a way to specify which keys should participate in the aggregation)

See the MuSig blogpost here: https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures.html and the ePrint here: https://eprint.iacr.org/2018/068.

This issue is being opened to discuss the requirements for standardization at the ecosystem layer (in native-multisignature mode) and for integration at the core layer (for the in-transaction cross-account multisignature mode).

[jedmccaleb]

Seems useful. Just need an SEP

[JeremyRubin]

@jedmccaleb we actually need a SEP and a CAP -- CAP would cover signature aggregation which would happen in core.

Maybe we should start with the SEP, and eventually move it to a CAP when we standardize it for core?

[MisterTicot]

@tomerweller

Very interesting proposal, indeed. I just red the article but I'm not sure about those points:

• Is it compatible with ed25519 or does it uses its own protocol?
• Does is allow weighted signers?
• Could signature agrégation happens at application level?

[JeremyRubin]

1. It is compatible with ed25519 curve
2. It does allow weighted signatures; but it's a bit more complicated (or really any monotone boolean circuit) and doesn't permit non-interactive setup
3. Yes, this can also happen but it is a bit more complicated to figure out which keys were used in signing,

[johansten]

m-of-m signatures can be done already, and is trivial on the application side since there's only one possible combination of signers. The resulting public key is a regular ed25519 public key that can be created as an account, and signed for.

With m-of-n signatures the resulting public key depends on which subset of m signers you have, so you can't really use it directly for most cases. You can create a merkle tree of the possible signers, and send a merkle proof instead, and have core (after a CAP) check that against the merkle tree root. So one signature, plus a merkle tree to prove that the signature is made by a relevant signer.

Weighted signatures, no clue. I never bothered to go that deep into the paper.

[theaeolianmachine]

@JeremyRubin do you want to write the SEP, or would you like someone else to take ownership?

[JeremyRubin]

Someone at interstellar should take part-ownership, I believe there is code which could be released for this purpose.

Someone else at SDF should take ownership of seeing it made available in high-quality library form (maybe @stanford-scs).

[johansten]

I have gotten m-of-m (http://github.com/future-tense/stellar-musig), and threshold signatures working on the application side. As mentioned above, these can be used to sign for an account, using one signature instead of many.

There's a bit of configuration and setup that could be standardized, but then we would still have the same problem that we have with regular multi-sig -- how to coordinate between different users, and different wallets. (Threshold signature setup is extra tricky since you might have to re-distribute shards if someone should happen to lose theirs.)

A system level integration would be slightly less complicated, since that would just be an m-of-m signature with the extra step of everyone first agreeing on who the m signers are going to be.