From: Jonas Nick <jonasdnick@gmail•com>
To: Olaoluwa Osuntokun <laolu32@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] MuSig2 BIP
Date: Thu, 28 Apr 2022 19:18:34 +0000 [thread overview]
Message-ID: <ca43c9b6-4219-9f6b-866a-ed7efcf17857@gmail.com> (raw)
In-Reply-To: <CAO3Pvs9sCU+zV9UPdrQ4xcF08vLy5zoA_4PUC6F5QjaHNo8uYA@mail.gmail.com>
Happy to hear that the BIP draft is already useful and thank you, Laolu, for
extracting the test vectors.
> an implementation must make the _pre tweaked_ combined key available to the caller
To apply the Taproot tweak with the key aggregation algorithm as specified you
would have to do the following (slightly simplified):
P := KeyAgg(pk_1, ..., pk_n, tweaks = [])
t := hash_TapTweak(P, root)
Q := KeyAgg(pk_1, ..., pk_n, tweaks = [t])
This unnecessarily recomputes the pre-tweaked key aggregate. In the BIP, there
are more places where the specified algorithms unnecessarily recompute certain
values. I believe this is justified if it makes the spec significantly easier to
understand. In this case, however, it's clear that calling KeyAgg multiple times
for the same set of public keys is not intuitive at all. This is something I had
not fully considered before. Thanks for bringing it up.
The approach you're taking in btcd makes a lot of sense to me. But in the
specification, we want to avoid specifying how exactly the tweaks are derived.
In the libsecp256k1-zkp implementation, key aggregation and tweaking are
separated into different functions. But this requires keeping state between key
aggregation and tweaking, which is why we had not chosen this approach for the
BIP. I will investigate how in the BIP, we can also split key aggregation and
tweaking and minimize complexity.
> My reading here is that [...] last party doesn't (?) need to worry about their
> nonces
Your reading is mostly right. Brandon describes correctly how and why to modify
the nonce generation algorithm. I opened a PR that replaces the description of
this signing mode with a precise specification. Indeed, the result is that the
last party doesn't need to worry about their nonce (even if the other parties
use bad randomness).
[0] https://github.com/jonasnick/bips/pull/11
next prev parent reply other threads:[~2022-04-28 19:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 22:57 Jonas Nick
2022-04-28 1:47 ` Olaoluwa Osuntokun
2022-04-28 3:53 ` Olaoluwa Osuntokun
2022-04-28 19:18 ` Jonas Nick [this message]
2022-05-22 22:26 ` AdamISZ
2022-05-23 15:56 ` Jonas Nick
2022-05-23 22:09 ` AdamISZ
2022-05-24 19:06 ` AdamISZ
2022-05-26 15:32 ` Jonas Nick
2022-05-26 17:34 ` AdamISZ
2022-06-12 23:07 ` AdamISZ
2022-10-03 20:41 ` Jonas Nick
2022-10-11 15:34 ` Jonas Nick
2022-11-03 14:43 ` Jonas Nick
2022-04-28 15:33 Brandon Black
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=ca43c9b6-4219-9f6b-866a-ed7efcf17857@gmail.com \
--to=jonasdnick@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=laolu32@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