Skip to content
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

Support one party managing several shares of secret data #1

Open
fjarri opened this issue Oct 12, 2024 · 0 comments
Open

Support one party managing several shares of secret data #1

fjarri opened this issue Oct 12, 2024 · 0 comments
Labels
enhancement New feature or request
Milestone

Comments

@fjarri
Copy link
Member

fjarri commented Oct 12, 2024

Imagine a threshold signing protocol. We may want to allow one party to keep several shares of the signing key to increase its "importance". Of course, one could just run several sessions concurrently using separate secret inputs for each share, but that is inefficient:

  • Sessions will have to send messages to other sessions running locally;
  • receive_message() methods will do extra work verifying proofs created locally;
  • Messages from the sessions will have to be sent separately, or somehow bundled together externally.

Alternatively, one could write a Round impl supporting owning multiple shares. It actually seems like a viable option in many cases - if you're a protocol author. But what if you're a user wanting to run an existing protocol this way? It would be nice to have manul support that. This will still require some support from the protocol level though, indicating which parts of the messages are proofs that can be ignored if the message is intended for the locally owned party.

@fjarri fjarri added the enhancement New feature or request label Oct 12, 2024
@fjarri fjarri added this to the v1.0.0 milestone Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant