derive or prove if single signer is part of the group on-chain

[SilentCicero]

Hi there,

Is there anyway I can derive or prove if a single signer is part of the group of signers on-chain without having the whole group sign, i.e. through the public key or a signature proof?

On-chain I mean Ethereum.

Thanks

[omershlo]

I am not sure I understand. Can you define the problem in terms of (1) input (2) output ?

[SilentCicero]

@omershlo yes, so let's say I have a Zen go wallet, and I want to prove I hold / own one of the key shards on Ethereum for a specific address, i.e. I want to prove I hold one of the shards for a specific multi-party address on Ethereum.

Would this be possible?

[omershlo]

Thanks @SilentCicero. Here is an answer I gave to a similar question we got on the telegram group :

Let's say signers use their accounts private keys as the secret shares for multiparty ecdsa.
In that case a signer will be able to tell which accounts participated in the signing.
In the case you have access only to the signature on chain it will be hard to detect accounts without further knowledge like the access structure and suspect accounts. 
In case there is a threshold it should be impossible to tell which specific accounts participated in a signature. 
If you have access to the public communication (as we suggest in our example code) you can get this type of accountability. 
Finally, it is interesting question if an account can prove in ZK that it's account was part of a given signing process given the signature.

Given the above answer - 1) This library supports having an account private key as a secret share 2) ZenGo is using 2 out of 2 scheme and therefore in this specific case it should be possible to publicly prove an account was one of the signers. If it is interesting we can think together on how exactly to do it in a secure way. A first guess: for the specific case of Lindell 2p ecdsa the secret shares are multiplicative: PK = s1 s2 G for generator G. Instead of proving for each signature you only need to prove knowledge of s1 once. I think that for that you need 2 elements: (1) the 2 party key generation transcript that includes dlog proof of knowledge of both s1 and s2 and a new proof of ddh that s1 used is the same for Q1 = s1 G and Pk = s1 Q2

[SilentCicero]

Thanks for this, and great stuff on this signature tech. Very cool

Sent from my iPhone

On Apr 18, 2020, at 2:45 PM, Omer Shlomovits notifications@github.com wrote:

Thanks @SilentCicero. Here is an answer I gave to a similar question we got on the telegram group :

Let's say signers use their accounts private keys as the secret shares for multiparty ecdsa. In that case a signer will be able to tell which accounts participated in the signing. In the case you have access only to the signature on chain it will be hard to detect accounts without further knowledge like the access structure and suspect accounts. In case there is a threshold it should be impossible to tell which specific accounts participated in a signature. If you have access to the public communication (as we suggest in our example code) you can get this type of accountability. Finally, it is interesting question if an account can prove in ZK that it's account was part of a given signing process given the signature.

Given the above answer -

This library supports having an account private key as a secret share ZenGo is using 2 out of 2 scheme and therefore in this specific case it should be possible to publicly prove an account was one of the signers. If it is interesting we can think together on how exactly to do it in a secure way. A first guess: for the specific case of Lindell 2p ecdsa the secret shares are multiplicative: PK = s1 s2 G for generator G. Instead of proving for each signature you only need to prove knowledge of s1 once. I think that for that you need 2 elements: (1) the 2 party key generation transcript that includes dlog proof of knowledge of both s1 and s2 and a new proof of ddh that s1 used is the same for Q1 = s1 G and Pk = s1 Q2 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.