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
A presignature is an interactive protocol with a prerequisite of two Beaver triples, but it can be computed offline. Requires 1 round of all-to-all ($n^2$) communication between participants.
Invariants
Presignatures should never be reused (even if the process failed mid through), so it is important to have mutually exclusive access to each of them.
Leaking presignature leaks the private key share, so it is very important to invest into a security layer for them
Presignatures do not require the payload to be known yet
Challenges
Consensus on which triples to use. Since nodes can start generating presignatures asynchronously they can cannibalize each other's ability to produce presignatures by using an overlapping set of triples. To overcome this we can mandate that every participant should only use triples proposed by them specifically.
Identification of presignatures. We need to route networking messages to generation protocol, so we need some way to distinguish presignatures before they are actually generated. One way to do this is by indentifying them by a pair (triple0, triple1) which should work, but I propose to use a separately generated random presignature id to reuse it at a later stage for signatures.
For future
This issue is focused on the core functionality, persistence layer and stockpiling are left for the future work
The text was updated successfully, but these errors were encountered:
Description
A presignature is an interactive protocol with a prerequisite of two Beaver triples, but it can be computed offline. Requires 1 round of all-to-all ($n^2$ ) communication between participants.
Invariants
Challenges
(triple0, triple1)
which should work, but I propose to use a separately generated random presignature id to reuse it at a later stage for signatures.For future
This issue is focused on the core functionality, persistence layer and stockpiling are left for the future work
The text was updated successfully, but these errors were encountered: