Used DKG instead of of a trusted dealer to create members' keys

[ppoliani]

Current solution supports the GenerateCommittee command that will create generate frost_keys for all members in one place i.e. trusted dealer. We should switch to using a distributed key generation flow so that each member's key is not exposed to anyone but themselves.

@mimoo there is this crate which looks like we could use. If it looks good with you, I could try create the first POC.

[mimoo]

We definitely need to tackle this sooner than later so thanks for posting the issue!

Isn't this crate for ed25519 only? I was under the impression that we could use the frost crate we're currently using and it would have the DKG functions.

There's a number of things we're trying to think about at the moment also:

1. How to use this scheme in a verifiable way: it'd be cool if we could post our public participation somewhere as a node (e.g. twitter), then have a link to all of the social network proofs of the different nodes. Then if someone wants to verify that the public key used by zkBitcoin is indeed the one resulting from a DKG of the published committee, they could use a tool to easily scrap proof data from the different participants and show that it indeed aggregate to that public key.
2. How to handle a dynamic committee. I know Sith Caith has a simple scheme for that. But we might want to look at what thorchain/dfinity/axelar do as they had to handle some of these issues as well. I also remember https://eprint.iacr.org/2019/1015.pdf which might be relevant
3. How to incentivize the committee to behave. The reference given in the previous point might help, but how cool would it be if we figured out a scheme where people could use L1 Bitcoins as collaterals.

more on DKR: https://hackmd.io/@omershlo/Hy1jBo6JY / https://github.com/ZenGo-X/fs-dkr and https://eprint.iacr.org/2021/339

[ppoliani]

Isn't this crate for ed25519 only? I was under the impression that we could use the frost crate we're currently using and it would have the DKG functions.

Oh sorry the one I shared is for ed25519 but there is one for secp256k1. Hmm, it looks like the code we have in our front.rs is quite similar to that. Oh I see, there are comments indicating that some part of that code is done in one place but should rather use some communication channel to share the relevant data. Ok, so we can use our orchestrator as the mediator of that communication (given we don't operate in a p2p network).

As I understand DKG is a generic protocol, right? I mean it doesn't matter what the underlying curve is? If that's the case then we could, in theory, adjust existing solutions to our needs.

I was under the impression that we could use the frost crate we're currently using and it would have the DKG functions.

Oh ok that makes sense now based what I wrote above.

How to use this scheme in a verifiable way

I don't know if it helps but I remember I have used a PVDKG protocol in the past. More specifically, it was an implementation of this paper. This was done in a threshold encryption scheme used in the ferveo project. I believe we could use that as reference.

How to handle a dynamic committee
The first part is probably done with a key-reshare process.

Is the committee open to public participation i.e. can anyone join the network? I did read some time the following discussions which I found quite interesting. This is in the context of a open dynamic committee (basically a blockchain with it's own concensus) where anyone can join, leave or removed (punished) from the set.

• Share replacement procedures & naming conventions, based on user/staker actions & application logic nucypher/ferveo#43
• Cohort Refresh – research (PSS) & product implications + validation nucypher/ferveo#70

scheme where people could use L1 Bitcoins as collaterals.

Sounds interesting. Can you share a bit more info about this idea? How would that work?

[0xBEEFCAF3]

Ok, so we can use our orchestrator as the mediator of that communication (given we don't operate in a p2p network).

That would make the most sense imo, if the orchestrator already has an authenticate/confidential networking setup. If not that would be the first step. The committee node (where the key lives) can then expose some authenticated endpoints for the orchestrator (add_round1_dkg_package, add_round2_dkg_package, get_verifying_key, etc...)

I was under the impression that we could use the frost crate we're currently using and it would have the DKG functions.

Yup. Secp256k1-tr works as is.

Is the committee open to public participation i.e. can anyone join the network? I did read some time the following discussions which I found quite interesting. This is in the context of a open dynamic committee (basically a blockchain with it's own concensus) where anyone can join, leave or removed (punished) from the set.

This is complicated. If new members are joining you have to prevent cybil attacks. One solution could be to have a voting process occur in some period where trusted orchestrators can vote in new ones. But you need consensus on this. And you need to perform DKG again if the signing set has changed. In the future, proactive secret sharing could help reduce the interactivity. Regardless the network should start with a known and trusted set of signers before adding new ones.

[mimoo]

more resources that could be useful: https://hackmd.io/@omershlo/Hy1jBo6JY / https://github.com/ZenGo-X/fs-dkr and https://eprint.iacr.org/2021/339

[0xBEEFCAF3]

Relevant DKG BIP: https://github.com/BlockstreamResearch/bip-frost-dkg

TLDR; Just having a confidential and encrypted setup for DKG is not enough to do this securely. You need to have consistency (each participant sees the same messages)