bitcoin-dev

BIP Draft: "ChillDKG: Distributed Key Generation for FROST"

BIP Draft: "ChillDKG: Distributed Key Generation for FROST"

Original Postby Tim Ruffing

Posted on: December 19, 2024 10:56 UTC

Significant revisions and enhancements have been made to the BIP draft since its initial announcement, as outlined in a recent update.

The changelog for version 0.2.0, dated December 19, 2024, highlights several critical improvements. These include fixing a security vulnerability where the CertEq signature did not previously cover the entire message, adding blame functionality with an investigation phase to identify faulty parties, ensuring that the threshold public key is Taproot-compatible by default, and allowing participants to encrypt their secret shares for themselves. This encryption approach uses symmetric encryption to minimize the overhead associated with ECDH computations. The updated BIP draft is accessible through the following GitHub link.

The team continues to seek feedback across various aspects, particularly from potential users and applications such as wallets. They aim to understand how well their design decisions and API meet the needs of potential applications or what improvements are necessary to enhance compatibility. Ongoing tasks include specifying the wire format and adding test vectors. Collaboration with siv2r, the author of a BIP draft for FROST signing (FROST signing BIP draft), is underway to ensure both proposals remain synchronized and compatible.

A specific issue raised concerns the protocol specification's reliance on Python code and the "secp256k1proto" package, which provides prototype operations essential for the protocol but is not formally part of the BIP. Plans to make this package available via the Python Package Index (PyPI) are in motion, though questions remain regarding how to best integrate this dependency into the BIPs repository. Three options were considered: maintaining a "git-subtree" of secp256k1proto within the BIPs repo, using a "git submodule" for the same purpose, or merely referencing an external package. The preference leans towards the first option, emphasizing the importance of keeping the BIPs repository self-contained and serving as a comprehensive archive, despite recognizing that each option has its trade-offs regarding repository cleanliness and archival integrity.