* [bitcoindev] BIP Draft: "ChillDKG: Distributed Key Generation for FROST" @ 2024-07-08 20:05 Tim Ruffing 2024-07-16 16:43 ` David A. Harding 2024-12-19 10:56 ` Tim Ruffing 0 siblings, 2 replies; 4+ messages in thread From: Tim Ruffing @ 2024-07-08 20:05 UTC (permalink / raw) To: bitcoindev Jonas Nick and I have been working on a BIP draft for Distributed Key Generation for FROST Threshold Signatures, which we would like to propose to the community for discussion. The draft contains a description of the design considerations, detailed usage instructions, and a reference implementation in Python, which we intend to be the definitive specification. The document and the code currently live at: https://github.com/BlockstreamResearch/bip-frost-dkg We're looking forward to feedback from the community. Things still to do include: * Specifying the wire format * Test vectors * Possibly any extensions currently mentioned as TODO in the draft (e.g., identifiable aborts) * Extracting the included secp256k1proto as a proper Python package Of course, a BIP for FROST *signing* will also be required to make use of FROST, and we know that one is in the works. Best, Jonas and Tim -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/8768422323203aa3a8b280940abd776526fab12e.camel%40timruffing.de. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoindev] BIP Draft: "ChillDKG: Distributed Key Generation for FROST" 2024-07-08 20:05 [bitcoindev] BIP Draft: "ChillDKG: Distributed Key Generation for FROST" Tim Ruffing @ 2024-07-16 16:43 ` David A. Harding 2024-07-16 17:31 ` Jonas Nick 2024-12-19 10:56 ` Tim Ruffing 1 sibling, 1 reply; 4+ messages in thread From: David A. Harding @ 2024-07-16 16:43 UTC (permalink / raw) To: Tim Ruffing; +Cc: bitcoindev On 2024-07-08 10:05, Tim Ruffing wrote: > Jonas Nick and I have been working on a BIP draft for Distributed Key > Generation for FROST Threshold Signatures Thank you Tim and Jonas! This looks amazing! One quick question; you write: > Simple backups: The capability of ChillDKG to recover devices from a > static seed and public recovery data avoids the need for secret > per-session backups, enhancing user experience. By "public recovery data", I assume you mean that security is not weakened by the data being made public. However, are there any privacy implications? For comparison, if everyone knows what BIP32 HD path I use, that doesn't weaken my privacy; but if everyone knows my BIP32 xpub, that pretty much destroys my onchain privacy. Where (if anywhere) does ChillDKG recovery data fall on this spectrum? Thanks again!, -Dave -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/5ce152c9181ea552b8e146c9329f011b%40dtrt.org. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoindev] BIP Draft: "ChillDKG: Distributed Key Generation for FROST" 2024-07-16 16:43 ` David A. Harding @ 2024-07-16 17:31 ` Jonas Nick 0 siblings, 0 replies; 4+ messages in thread From: Jonas Nick @ 2024-07-16 17:31 UTC (permalink / raw) To: David A. Harding, Tim Ruffing; +Cc: bitcoindev Thanks Dave. There are indeed potential privacy implications of the recovery data because only the secret shares are encrypted. Most importantly, the recovery data contains in plaintext: - the long-term "host" public keys of the participants - the final threshold public key that is the result of the DKG For example, we could imagine a scenario where a DKG participant puts their recovery data on a cloud hoster and an adversary is able to obtain it. Then the adversary could use to contained threshold public key to associate on-chain transactions with the victim. However, there's nothing preventing the participants from encrypting the recovery data before backing it up. We do not specify that encryption in the BIP because it is an operation local to the participants and does not affect the communication between them. But now that you mention this, I think we should be a bit more clear in the BIP (and don't call the recovery data "public"). For example, it may make sense to use the DKG protocol seed to derive an encryption key, so you don't have to backup any secret data besides the seed. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/7084f935-0201-4909-99ff-c76f83572a7c%40gmail.com. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoindev] BIP Draft: "ChillDKG: Distributed Key Generation for FROST" 2024-07-08 20:05 [bitcoindev] BIP Draft: "ChillDKG: Distributed Key Generation for FROST" Tim Ruffing 2024-07-16 16:43 ` David A. Harding @ 2024-12-19 10:56 ` Tim Ruffing 1 sibling, 0 replies; 4+ messages in thread From: Tim Ruffing @ 2024-12-19 10:56 UTC (permalink / raw) To: bitcoindev; +Cc: Jonas Nick We made many changes, improvements, and cleanups to our BIP draft since our first announcement to this mailing list. From the Changelog: 0.2.0 (2024-12-19): In addition to various readability improvements to specification and reference implementation, the following major changes were implemented: * Fix security vulnerability where the CertEq signature did not cover the entire message. * Add blame functionality to identify faulty parties, including an investigation phase. * Make threshold public key Taproot-safe by default. * Let each participant encrypt the secret share intended for themselves so that it can be decrypted instead of re-derived during recovery. The encryption is symmetric to avoid the overhead of an ECDH computation. The current version of the full BIP draft can be found here: https://github.com/BlockstreamResearch/bip-frost-dkg We are still actively looking for feedback of any kind (here or in our GitHub repo). This includes feedback from potential users and applications (e.g., wallets). We'd be very interested to hear if our design decisions and the API fit potential applications, or what can be improved to make them fit more. Things still to do include: * Specifying the wire format * Adding test vectors We are in touch with siv2r, the author of a BIP draft for FROST signing ( https://github.com/siv2r/bip-frost-signing ) to keep the proposals in sync and compatible with each other. As we want to open a PR to the BIPs repo soon, here's a specific issue that we'd like to hear the community's and in particular the BIP editors' opinion on: Our protocol specification is Python code. It relies on a package "secp256k1proto", which contains simple prototype operations of basic buildings block of the protocol that we assume given, e.g., an implementation of the secp256k1 elliptic curve and BIP340 signatures. While secp256k1proto is technically not part of the BIP, it will be necessary to run the reference implementation. We plan to extract this code into a proper package and make it available via the the Python Package Index (PyPI). However, we are unsure what this would for files associated to our BIP in the BIPs repo. These are the possibilities we considered: 1. Keep a "git-subtree" of secp256k1proto along with the reference implementation in the BIPs repo. 2. The same as 1., but make it a "git submodule". 3. Only refer to an external package secp256k1proto + version number (or hash) in the reference implementation, possibly with descriptions of what the imported functionality does (e.g., if our reference implementation uses the "+" operator on EC points, we'd write down that this is supposed to implement point addition). Our current thinking is that option 1 is the best. It has the advantage that the BIPs repo will be fully self-contained and serves as a definitive archive. Option 2 is worse in terms of archival. git submodules are not guaranteed to be included in clones, and we'd need to host the submodule somewhere else. Moreover, git submodules can be a mess. Option 3 is possible and keeps the BIPs repo lean, but we believe that keeping the repo lean should not be a primary concern. Moreover, if we want to add human-readable descriptions of the functionality we use from secp256k1proto, the most natural and convenient way do this is via Python docstrings, but these will require shipping the actual code (option 1 or 2), since there is no pythonic way to specify just an interface without its implementations similar to, e.g., C header files. Best, Jonas and Tim On Mon, 2024-07-08 at 22:05 +0200, Tim Ruffing wrote: > > Jonas Nick and I have been working on a BIP draft for Distributed Key > > Generation for FROST Threshold Signatures, which we would like to > > propose to the community for discussion. The draft contains a > > description of the design considerations, detailed usage > > instructions, > > and a reference implementation in Python, which we intend to be the > > definitive specification. The document and the code currently live > > at: > > > > [https://github.com/BlockstreamResearch/bip-frost-dkg](https://github.com/BlockstreamResearch/bip-frost-dkg) > > > > We're looking forward to feedback from the community. > > > > Things still to do include: > > * Specifying the wire format > > * Test vectors > > * Possibly any extensions currently mentioned as TODO in the draft > > (e.g., identifiable aborts) > > * Extracting the included secp256k1proto as a proper Python package > > > > Of course, a BIP for FROST *signing* will also be required to make > > use > > of FROST, and we know that one is in the works. > > > > Best, > > Jonas and Tim > > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/17fc9514030108a99c14b66f2e5ef2d28f970593.camel%40timruffing.de. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-12-19 11:01 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-07-08 20:05 [bitcoindev] BIP Draft: "ChillDKG: Distributed Key Generation for FROST" Tim Ruffing 2024-07-16 16:43 ` David A. Harding 2024-07-16 17:31 ` Jonas Nick 2024-12-19 10:56 ` Tim Ruffing
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox