Open kayabaNerve opened 1 month ago
Abstracted DKG's also may enable including obscure DKGs such as Monero's ECDH-premised DKG. I'm unsure it would in practice as Monero's DKG may not yield verification shares. While we could offer VerifiableBiasedKeyShare/VerifiableUnbiasedKeyShare (or rather Verifiable + Unbiased + KeyShare
), I'm unsure we actually want to support algorithms without identifiable aborts.
The current
dkg
crate (or the one on thenext
branch) should be published as 1.0. That doesn't change it has flaws we should fix.1)
dkg
shouldn't actually have any DKGs. It should just be theThresholdKeys
type. PedPoP should be moved to its own crate, as should Musig (which I did register the crates for). This would allow anyone to add their own DKG, such as Chill DKG. 2) Only having additive offsets/lagrange interpolation is insufficient. We should support multiplicative offsets, additive offsets, and either constant or lagrange interpolation (as seen with thedkg
crate on thenext
branch). This was also noted in #195. 3) ReplacingThresholdKeys
withBiasedKeyShare
andUnbiasedKeyShare
. This would allow higher-level protocols to specify which they need (Bitcoin needs a tweaked biased key or an unbiased key, Ethereum needs an unbiased key if the key is fed into keccak160 as addresses are).Multiplicative offsets will be needed by the time Carrot comes around (the Monero FCMP++ hard fork) yet we shouldn't start working on this before Serai launches.
195 was closed as it was cool things for a 2.0 yet nothing with concrete benefit. All of these do have concrete benefit, hence this issue existing now and standing.