bitcoin-dev

Combined summary - BIP Draft: "ChillDKG: Distributed Key Generation for FROST"

Combined summary - BIP Draft: "ChillDKG: Distributed Key Generation for FROST"

Jonas, Nick, and Tim have embarked on a significant project to draft a Bitcoin Improvement Proposal (BIP) that centers around Distributed Key Generation (DKG) for FROST Threshold Signatures.

Their mission is to circulate this draft within the community for further review and constructive feedback. The essence of their work includes not just theoretical design but also practical guidelines and a Python-based reference implementation, all aimed at setting a standard for this cryptographic procedure. They are hosting their ongoing work and documentation on GitHub, providing an open invitation for community engagement through this link.

Despite the progress, there are still several areas that require attention and development. These areas include finalizing the wire format, creating test vectors, resolving outstanding extensions such as identifiable aborts, and formalizing the secp256k1proto Python package. Furthermore, they acknowledge that implementing FROST will necessitate another separate BIP tailored for FROST signing, highlighting the comprehensive nature of this endeavor and its implications for future cryptographic practices in Bitcoin. This initiative underscores a collaborative push towards refining and advancing the cryptographic foundations of Bitcoin, with Jonas, Nick, and Tim playing pivotal roles in this advancement.

A particular point of discussion that has emerged pertains to the privacy considerations surrounding the recovery data involved in the DKG process. It was highlighted that while secret shares are encrypted, the recovery data—which includes long-term "host" public keys and the final threshold public key—remains in plaintext. This raises potential privacy concerns, as an adversary gaining access to this data could potentially link on-chain transactions to specific individuals. While participants can encrypt this data before backup, the original documentation did not mandate this encryption, focusing instead on operations local to the participants that do not impact inter-participant communication. This oversight has prompted a reevaluation of how recovery data is described in the BIP, considering the use of the DKG protocol seed for deriving an encryption key as a more secure alternative to backing up the recovery data.

Discussion History

0
Tim RuffingOriginal Post
July 8, 2024 20:05 UTC
1
July 16, 2024 16:43 UTC
2
July 16, 2024 17:31 UTC