-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Identifiable Abort #111
Comments
|
It's a good feature to have, but I don't think we're going to work on it in any near future. It's also something that is difficult to contribute, as it's a massive change, and we'd need the contribution to comply with certain requirements (e.g. that identifiable abort is optional, and when not enabled it doesn't affect performance; code quality; architectural changes need to be discussed in advance), so if you want to volunteer for contribution it would imply that we need to have a lot of discussions before the work can be started, and we'd need to keep in touch after that and review intermediate progress, to make sure that we're all aligned on the feature development. |
If you want to communicate with us about IA, you can also join our discord room https://discordapp.com/channels/905194001349627914/1285268686147424388 |
Feature request
You mention in the README file that the identifiable abort (IA) feature is not fully supported. At Nillion, we are interested in integrating this feature in the 3+1 protocol version.
Q1: Are you already working on this? Otherwise, we would like to contribute.
Implementation details
We've looked into the code and it seems that most of the ZK-protocols are already implemented together with the
blame
option, allowing to have some degree of IA. According to the docs, there are two ways to request a signature:cggmp21::signing
, which ends up callingsigning_n_out_of_n
and runs the whole signing protocol at once,generate_presignature
->issue_partial_signature
->combine
.To support IA following option 1, we would need to include 3 new zkps ($\Pi^{mul}$ , $\Pi^{mul*}$ and $\Pi^{dec}$ ) into paillier-zk repo and integrate them here and here.
Option 2 seems a bit more evolving as we would need to save the transcripts in-between the function calls.
Q.2 Is the above sensible? Are we missing any major blocker?
The text was updated successfully, but these errors were encountered: