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

User can participate in signing #379

Merged
merged 25 commits into from
Sep 2, 2023
Merged

Conversation

ameba23
Copy link
Contributor

@ameba23 ameba23 commented Jul 28, 2023

If key visibility is private, we should assume the user is also going to connect to the threshold servers and participate in the signing process.

Because of this, i have changed the key visibility used in our existing tests to use 'permissioned', so the vanilla case we test for does not require participation from the user.

As explained in the related issue #362 making this practical to use from the SDK will also require having wasm bindings for Synedrion's sessions API.

@vercel
Copy link

vercel bot commented Jul 28, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
entropy-core ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 2, 2023 0:02am

@ameba23
Copy link
Contributor Author

ameba23 commented Jul 28, 2023

Having starting trying to write a test for this, my feeling is that it might make sense that rather than having JS bindings for synedrion's signing session API, we could have wasm-compilable crate with a function which handles the connecting, handshaking and executing signing protocol, which is called by the SDK and passed a keyshare and an array of validator info.

Although this could all be done from JS and there are good noise implementations in JS, i feel like we would be repeating a lot of work we already have here, and would make things harder to maintain.

@ameba23
Copy link
Contributor Author

ameba23 commented Aug 4, 2023

Test currently failing with:
thread 'user::tests::test_sign_tx_user_participates' panicked at 'called Option::unwrap()on aNone value', /home/turnip/.cargo/git/checkouts/synedrion-d2f4837b6efbe779/bfc23e6/synedrion/src/protocols/signing.rs:92:10

coming from this line in Synedrion.

and i am not sure why - relevant part of stack trace:

4: <synedrion::protocols::signing::Round1 as synedrion::protocols::generic::Round>::finalize
             at /home/turnip/.cargo/git/checkouts/synedrion-d2f4837b6efbe779/bfc23e6/synedrion/src/protocols/signing.rs:86:19
   5: <synedrion::protocols::interactive_signing::SigningRound as synedrion::protocols::generic::Round>::finalize
             at /home/turnip/.cargo/git/checkouts/synedrion-d2f4837b6efbe779/bfc23e6/synedrion/src/protocols/interactive_signing.rs:314:9
   6: synedrion::sessions::type_erased::RoundAndAccum<R>::finalize_typed
             at /home/turnip/.cargo/git/checkouts/synedrion-d2f4837b6efbe779/bfc23e6/synedrion/src/sessions/type_erased.rs:66:15
   7: <synedrion::sessions::type_erased::RoundAndAccum<R> as synedrion::sessions::type_erased::TypeErasedReceivingRound<<R as synedrion::protocols::generic::Round>::Result>>::finalize
             at /home/turnip/.cargo/git/checkouts/synedrion-d2f4837b6efbe779/bfc23e6/synedrion/src/sessions/type_erased.rs:206:15
   8: synedrion::sessions::states::ReceivingState<Res,Sig,Signer,Verifier>::finalize_regular_round
             at /home/turnip/.cargo/git/checkouts/synedrion-d2f4837b6efbe779/bfc23e6/synedrion/src/sessions/states.rs:348:15
   9: synedrion::sessions::states::ReceivingState<Res,Sig,Signer,Verifier>::finalize
             at /home/turnip/.cargo/git/checkouts/synedrion-d2f4837b6efbe779/bfc23e6/synedrion/src/sessions/states.rs:389:45
  10: server::signing_client::new_party::signing_protocol::execute_protocol::{{closure}}::{{closure}}
             at ./src/signing_client/new_party/signing_protocol.rs:136:15

so this line in execute_protocol.

@ameba23
Copy link
Contributor Author

ameba23 commented Aug 8, 2023

For the record, the problem was caused by calling make_interactive_signing_session with only two verifier keys (missing the verifier key for the user), and that the validators began executing the protocol without waiting for the user to connect, effectively causing protocol messages destined for the user to be ignored.

This meant the signing protocol ran, but failed when checking the signature, as a required signing party was missing.

@@ -80,13 +82,17 @@ impl Default for SignatureState {
pub async fn do_signing(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason we are now passing the app_state struct here is because otherwise clippy complains that there are now too many arguments to this function.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that is fine, you could also put in an ignore for clippy in the future if you want


for validator in validators_info {
if &validator.tss_account != my_id {
validators.insert(validator.tss_account, validator.x25519_public_key);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we also store the x25519 public key, so that when validators connect we can check both Account ID and x25519 public key. This is needed for one of our negative tests where a bad x25519 public key is passed.

@ameba23 ameba23 marked this pull request as ready for review August 17, 2023 14:11
@ameba23 ameba23 requested a review from JesseAbram August 17, 2023 14:11
@@ -80,13 +82,17 @@ impl Default for SignatureState {
pub async fn do_signing(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that is fine, you could also put in an ignore for clippy in the future if you want

@ameba23 ameba23 merged commit 13d7f3f into master Sep 2, 2023
@ameba23 ameba23 deleted the user-participates-in-signing branch September 2, 2023 12:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants