ZenGo-X / multi-party-ecdsa

Hi,
I have problem with signing a "hello" sentence in the GG20 example.
I am trying commands from the example and the result is:

Error: online stage failed

Caused by:
couldn't complete signing: round 7: InvalidSig

Please give me a small advice :) What I am doing wrong.

Hi @eatruffle, what are exact commands you executed that produce the error?

Hi,

first of all thank you for this amazing project, and for interest of my question.
All comments, I am taking from the GG20 demo,

In ./target/release/examples/ folder,

I am starting the manager ./gg20_sm_manager
After this, in three different terminals I am running

./gg20_keygen -t 1 -n 3 -i 1 --output local-share1.json
./gg20_keygen -t 1 -n 3 -i 2 --output local-share2.json
./gg20_keygen -t 1 -n 3 -i 3 --output local-share3.json

And last:
Also, in two different terminals
./gg20_signing -p 1,2 -d "hello" -l local-share1.json
./gg20_signing -p 1,2 -d "hello" -l local-share2.json

And the result is

Error: online stage failed

Caused by:
couldn't complete signing: round 7: InvalidSig

Confirm, it reproduces for me with some probability. Not sure what's exact problem. cc @elichai @MatanHamilis

Hi
I have modified the if statement below line 900

multi-party-ecdsa/src/protocols/multi_party_ecdsa/gg_2020/party_i.rs

Line 900 in c80c87d

let ver = verify(&sig, &self.y, &self.m).is_ok();

and is OK
Now I am checking what exactly is wrong with input parameters for this function.

I'm getting a similar error, but it fails in round6. Did y'all get a chance to look into it? @survived @elichai @MatanHamilis

Can confirm this happens with some probability on our end too:

Incorrect Alice's range proof in MtA: InvalidKey

Hello everyone!
@drewstone I think your error might be a duplicate of #165. At least I was only able to reproduce it when trying to sign with incorrect keys/keys in the incorrect order.
@eatruffle I'm not sure what is the modification you're suggesting. Anyway, after playing around a little bit, I noticed that sometimes partial signatures that the parties are receiving (here they are: https://github.com/ZenGo-X/multi-party-ecdsa/blob/master/examples/gg20_signing.rs#L78) are their own. I.e. when party 1 and party 2 are signing a message, during the last round, party 1 should send their share to party 2 and vice versa. Instead, sometimes party 1 ends up with their own share and 2 with their own. Needless to say, in such cases, they are unable to sign. The problem is that indices assigned to parties during the offline stage of signing might differ from indices assigned to parties during the online stage. My solution is to simply remove _ from _i here: https://github.com/ZenGo-X/multi-party-ecdsa/blob/master/examples/gg20_signing.rs#L58, so that the new index shadows variable i and is used in the subsequent exchange of messages (as it probably should). @survived, do you agree?
In any case, I think the error originates in the demo, and not the main library code, which is probably good news

@MatanHamilis could we maybe implement this fix? It's a one-liner, I'll do the PR
Also, I could write a better user guide for the demo as at least two people got confused by running parties in the incorrect order and getting errors.
Finally the most important addition to README imo - stating explicitly that GG18 in its current form is insecure (there were also questions about that)

@MatanHamilis could we maybe implement this fix? It's a one-liner, I'll do the PR Also, I could write a better user guide for the demo as at least two people got confused by running parties in the incorrect order and getting errors. Finally the most important addition to README imo - stating explicitly that GG18 in its current form is insecure (there were also questions about that)

Hey, I also have the problem of getting the InvalidSig error from time-to-time. Did we get a chance to confirm and push the fix for it?

Finally the most important addition to README imo - stating explicitly that GG18 in its current form is insecure (there were also questions about that)

Could you expand on why gg18 is insecure?

@0xYao I believe the fix hasn't been implemented yet. As to the (in)security of gg18: the current ZenGo implementation does not use range proofs for MtA subprotocol which was shown to be insecure. The problem is solved in the implementation of gg20.

@MatanHamilis could we maybe implement this fix? It's a one-liner, I'll do the PR Also, I could write a better user guide for the demo as at least two people got confused by running parties in the incorrect order and getting errors. Finally the most important addition to README imo - stating explicitly that GG18 in its current form is insecure (there were also questions about that)

Thanks for your help. Despite your advice, I still face this issue. Even if run signing clients in the right order.

Error: online stage failed

Caused by:
    couldn't complete signing: round 7: InvalidSig

I did the same steps from the tutorial. But unfortunately, sometimes got this issue. Do you know how to prevent this problem?

@MatanHamilis could we maybe implement this fix? It's a one-liner, I'll do the PR Also, I could write a better user guide for the demo as at least two people got confused by running parties in the incorrect order and getting errors. Finally the most important addition to README imo - stating explicitly that GG18 in its current form is insecure (there were also questions about that)

Thanks for your help. Despite your advice, I still face this issue. Even if run signing clients in the right order.
Error: online stage failed

Caused by:
    couldn't complete signing: round 7: InvalidSig
I did the same steps from the tutorial. But unfortunately, sometimes got this issue. Do you know how to prevent this problem?

Problem is solved. Just remove _ from _i here, as @DmytroTym mentioned above.
https://github.com/ZenGo-X/multi-party-ecdsa/blob/master/examples/gg20_signing.rs#L58

Problem with gg20