Hi @conradoplg. I’m Daniel Gorgonha, and I write the code of Konclave, the group vault this thread is about. We haven’t talked before, so let me start with a thank you: Konclave is built on the Foundation’s FROST work, and the design we are writing follows the direction you described for DKG in ZIP 312.
We are preparing a ZCG application, and there are two points where your view would help us get that design right, whenever you have time.
Creating the viewing key on a device. Today our coordinator creates each vault’s viewing key: it runs the Foundation’s signing tool with the vault’s group key, so nk and rivk come from a random sk, through the constructor you suggested keeping for now (frost tools issue 591). The coordinator then keeps the viewing key. We would like one member’s device to create sk instead and seal it to the other members, so the coordinator never holds the viewing key. Spending stays with the group key from the DKG either way. Is there anything you would do differently in moving that step onto a device?
Quantum recoverability. We read the “Usage with FROST” section of ZIP 2005. Every participant keeps qsk, and the ZIP notes that a quantum adversary may be able to steal the funds with qsk alone. Our reading is that, for a threshold vault, recovery becomes one of n. Our vaults have no quantum recovery today, since orchard main has no qsk derivation yet. Is that the Foundation’s reading too, or is the key generation work for ZIP 312 (zips issue 1051) heading somewhere that keeps the threshold?
No rush, and if another place suits you better, we are happy to continue there. Thank you.