ChillDKG was originally drafted back in 2024 by Tim Ruffing, Jonas Nick, Illia Melnyk, Mariia Zhvanko, and Sivaram Dhakshinamoorthy. Development seems to have continued because there is now a recent PR to add it to the BIPs repository.

Normal multisig using segwit has a bigger footprint and is pretty obvious that it's a multisig onchain. Taproot helps with this a little because you don't have to reveal all the spent paths when you spend. FROST takes it to a whole new level by having all the singers only hold a share of the key that does the signing.

The setup process however can be cumbersome. This draft BIP outlines a nicely streamlined method for creating a FROST key in such a way that the full key never exists in one place. Onchain, it just looks like a single signature.

I very excited about FROST and love to see developments along these lines.

Here is a nice explanation of ChillDKG from the motivation section of the BIP:

The FROST threshold signature scheme [KG20, CKM21, BTZ22, CGRS23] enables t-of-n Schnorr signatures, in which some threshold t of a group of n participants is required to produce a signature. FROST guarantees unforgeability as long as at most t - 1 participants are compromised and remains functional as long as t honest participants do not lose their secret key material, where t and n can be chosen arbitrarily (as long as 1 <= t <= n).¹ As a result, threshold signatures increase both security and availability, enabling users to escape the inherent dilemma between the contradicting goals of protecting a single secret key against theft and data loss simultaneously.

BIP 445 provides a specification of the FROST signing protocol tailored to BIP 340 Schnorr signatures as deployed in Bitcoin. However, in order to use the specified protocol, the participants need to generate a shared threshold public key (representing the entire group with its t-of-n policy), together with n corresponding secret shares (held by the n participants) that allow to sign under the threshold public key. This key generation can, in principle, be performed by a trusted dealer who takes care of generating the threshold public key as well as all n secret shares, which are then distributed to the n participants via secure channels. However, the trusted dealer constitutes a single point of failure: a compromised dealer can forge signatures arbitrarily.

An interactive distributed key generation (DKG) protocol session by all participants avoids the need for a trusted dealer. There exist a number of DKG protocols with different requirements and guarantees in the cryptographic literature. Most suitable for the use with FROST is the PedPop DKG protocol [KG20, CKM21, CGRS23] ("Pedersen DKG [Ped92, GJKR07] with proofs of possession"), which, like FROST, does not impose restrictions on the choice of t and n.

But similar to most DKG protocols in the literature, PedPop has strong requirements on the communication channels between participants, which make it difficult to deploy in practice: First, it assumes that participants have secure (i.e., authenticated and encrypted) channels between each other, which is necessary to avoid man-in-the-middle attacks and to ensure confidentiality of secret shares when delivering them to individual participants. Second, PedPop assumes that all participants have access to some external consensus or reliable broadcast mechanism that ensures they have an identical view of the protocol messages exchanged during DKG. This will, in turn, ensure that all participants eventually reach agreement over the results of the DKG, which include not only parameters such as the generated threshold public key but also whether the DKG has succeeded at all.

To understand the necessity of reaching agreement, consider the example of a DKG to set up a 2-of-3 Bitcoin wallet in which two participants are honest but the third participant is malicious. The malicious participant sends invalid secret shares to the first honest participant, but valid shares to the second honest participant. While the first honest participant cannot finish the DKG, the second honest participant will believe that the DKG has finished successfully and thus may be willing to send funds to the resulting threshold public key. But this constitutes a catastrophic failure: Those funds will be lost irrevocably because the single remaining secret share of the second participant will not be sufficient to produce a signature (without the help of the malicious participant).²

To sum up, there is currently no description of PedPop that does not assume the availability of external secure channels and consensus and thus can be turned into a standalone implementation. To overcome these issues, we propose ChillDKG in this BIP. ChillDKG is a variant of PedPop with "batteries included", i.e., it incorporates minimal but sufficient implementations of secure channels and consensus and thus does not have external dependencies. This makes it easy to implement and deploy, and we provide detailed algorithmic specifications in the form of Python code.