You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
burdges
changed the title
How should we expose the aggregate public key method for multi-signatures?
Improve aggregate public key handling
Feb 13, 2019
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 callcompute_R
incosign_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.
The text was updated successfully, but these errors were encountered: