From: Tim Ruffing <crypto@timruffing•de>
To: bitcoindev@googlegroups.com
Cc: Jonas Nick <jonasdnick@gmail•com>
Subject: Re: [bitcoindev] BIP Draft: "ChillDKG: Distributed Key Generation for FROST"
Date: Thu, 19 Dec 2024 11:56:40 +0100 [thread overview]
Message-ID: <17fc9514030108a99c14b66f2e5ef2d28f970593.camel@timruffing.de> (raw)
In-Reply-To: <8768422323203aa3a8b280940abd776526fab12e.camel@timruffing.de>
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.
prev parent reply other threads:[~2024-12-19 11:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 20:05 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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17fc9514030108a99c14b66f2e5ef2d28f970593.camel@timruffing.de \
--to=crypto@timruffing$(echo .)de \
--cc=bitcoindev@googlegroups.com \
--cc=jonasdnick@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox