BIP Draft: ChillDKG: Distributed Key Generation for FROST

[mllwchrry]

This PR adds a BIP for the ChillDKG distributed key generation protocol intended to be used with BIP 445 (FROST Signing). The development repository is at https://github.com/BlockstreamResearch/bip-frost-dkg.

Remaining items to do:

• Test vector coverage is already quite good, but we'd like to add a few additional test vectors (More test vectors BlockstreamResearch/bip-frost-dkg#138) and also make them a bit more convenient to use (Group input-validation error cases in test vectors so they can be skipped BlockstreamResearch/bip-frost-dkg#121). (Note to implementors: After all, this is still a draft. There's no guarantee that already existing vectors won't change.)
• We'd like to add a warning and a reference to BIP 445 once the adaptive security issue has been dealt with there. (Restrict or warn on (n, t) parameters vulnerable to adaptive security attack BlockstreamResearch/bip-frost-dkg#126)
• While we tried to be consistent and compatible with BIP 445, some smaller changes may be warranted depending on some final changes in BIP 445. For example, we want to make sure that the DKGOutput data structure of the reference code here matches what BIP 445 expects as input (Align the DKGOutput datatype to what BIP445 expects as input BlockstreamResearch/bip-frost-dkg#157).

Feedback is very much appreciated! Please comment on this pull request or open an issue at https://github.com/BlockstreamResearch/bip-frost-dkg for any feedback. Thank you!

Disclosure: AI has been used in the later stages of drafting for proof reading as well as refactoring and reviewing certain sections of the reference code.

Note to editors: Despite there being a handful of things we still plan to improve, we're opening this PR intentionally not as a draft PR to indicate that the BIP draft is in a shape ready for review by the community. Should you disagree with this decision, simply convert the PR to draft.

[DarkWindman]

How did you solve the ice problem...?

Thanks for the question — I assume you mean identifiable cheating entities, as in ICE-FROST?

ChillDKG does identify faulty parties. Whenever a session aborts, an honest party will blame at least one participant or the coordinator. If a participant receives incorrect secret shares and cannot immediately tell who is responsible, it can request an auxiliary investigation message from the coordinator, which lets it single out the faulty participant.

The guarantees are deliberately limited. Blame is conditional on reliable communication links, and a participant blaming another participant additionally relies on an honest coordinator.

Most importantly, ChillDKG is not robust by design: the session aborts instead of continuing without the faulty party (see the "Robustness is Not a Goal" section). Excluding a participant would degrade the setup from t-of-n to (t-1)-of-(n-1) from the outset, and would hand a faulty coordinator the power to exclude participants at will.

[jonatack]

@leviwinks please stop spamming here with long, unrelated comments. Thank you.