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.

[murchandamus]

I started reading this submission. I got up to Internals of ChillDKG. I left a few questions and comments inline.

Beyond minor formatting issues, the submission appears high-quality and comprehensive. I noticed that the document is currently missing the required Backwards Compatibly section, and while there are sections that I identify as containing Specification and Rationale, they are currently titled differently.

[murchandamus]

Nit: Title is already mentioned in the preamble.

[murchandamus]

Not kept confidential from other participants or not kept confidential from the public?

[DarkWindman]

From the public. I think the wording “which is common to all participants and does not need to be kept confidential” is a bit confusing. Essentially, the point is that since the recovery data contains all the aggregated data, it is shared among all participants, so backups are not participant-specific, and a participant who loses their copy can re-obtain it from any other party. By “confidentiality” here, I think we actually mean that it cannot be used to recover any secret key material or otherwise compromise the protocol: all sensitive values are already encrypted. However, it is important to note, that the remaining fields do reveal session metadata, that is why in Backup and Recovery section note that the user can encrypt the recovery data before sending. It's also worth noting that to actually use this data (recover a secshare), a user must apply their hostsecretkey. If they’ve lost that key as well, recovery is impossible.

[murchandamus]

The coordinator needing to be reliable in order to be able to blame a failure on the coordinator sounds contradictory.

[DarkWindman]

An honest coordinator is required only when a participant blames another participant. Since the coordinator relays all messages, a malicious one can make an honest participant blame another honest participant.
We strictly distinguish between these cases in the implementation: where the coordinator might have had an impact and a participant cannot be certain of the suspect's guilt, we raise a FaultyParticipantOrCoordinatorError.

Blaming the coordinator itself never requires the coordinator to be honest.

@real-or-random may want to weigh in here.

[real-or-random]

This is indeed subtle.

The only guarantee the protocol provides is this:

Suggested change

	If a ChillDKG session fails due to the participants or the coordinator deviating from the protocol,
	any aborting party will be able to identify and blame a single party responsible for the failure
	(assuming the network, and, depending on the circumstances, the coordinator, are reliable).
	If a ChillDKG session fails due to one or more participants deviating from the protocol,
	any aborting party will be able to identify and blame a single participant responsible for the failure
	(assuming the network and the coordinator are reliable).

But just writing it like that will also be confusing to the reader because the code has also paths where a failing participant blames the coordinator. But the purpose of these code paths is just debugging broken coordinators, and there's no guarantee that an actively malicious coordinator can be caught (as it can always make an honest participant A blame another honest participant B by mis-relaying a message from B as @DarkWindman explains).

We'll need to see how to phrase this clearly.

[murchandamus]

In line 40, t is restricted per 1 <= t <= n. Is the same threshold range applicable here? I suspect that t = 0 would not be acceptable?

[DarkWindman]

Yes, we inherit the threshold constraint from line 40 (1 <= t <= n), and therefore t = 0 is excluded.
I agree the bounds look incomplete here, but this bullet is really about the value of t specifically in relation to n, relying on the general bound from FROST mentioned above.
We'll fix this to make it clearer.

[DarkWindman]

Thank you, @murchandamus, for the review! I've replied to the inline comments and we'll fold the changes into the next update.
Looking forward to the rest of your pass.

[aakselrod]

This is looking amazing. I've started working on adding the new recovery acknowledgments to my implementation and would really appreciate having test vectors for that as well.

Also a small nit, and not necessary if you don't want to do it, but test group IDs might also be nice in the vectors where there are multiple test groups, similar to what BIP-0445 does.