w3f / schnorrkel

Schnorr VRFs and signatures on the Ristretto group
BSD 3-Clause "New" or "Revised" License
309 stars 93 forks source link

Improve aggregate public key handling in musig #12

Open burdges opened 5 years ago

burdges commented 5 years ago

First, how should we expose the aggregate public key method for multi-signatures?

We currently have some tools to compute public keys form slices of public keys, as well as to expose the aggregate public key counting all revealed participants. We currently lack tests to ensure these agree, but beyond this should we add methods to answer queries about the aggregate public keys at each stage? Or would this be confusing?

Second, should we error when users attempt to progress form one stage to another without the aggregate public key being correct?

We'd improve errors if users attempted to put themselves into irrecoverable states. We do want a remove method for public keys that abandon the protocol. We call compute_R in cosign_stage so deletion cannot happen after people enter that stage. Yet, doing too much may limit the utility, like by preventing users from creating their R shares in advance.

Third, should protocol messages communicate the signer list and/or be signed?

We need agreement on the set of cosigners of course, but initially I wanted to be agnostic to the agreement technique.

As an aside, there are likely strange attacks without the commit phase, like Eve might join Eve-Alice and Eve-Bob, but the commit stage prevents these.

burdges commented 5 years ago

We should likely sign the last message along with the list of public keys that revealed correctly.