[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    Re: [bitcoin-dev] MuSig2 BIP
From:       Jonas Nick via bitcoin-dev <bitcoin-dev () lists ! linuxfoundation ! org>
Date:       2022-04-28 19:18:34
Message-ID: ca43c9b6-4219-9f6b-866a-ed7efcf17857 () gmail ! com
[Download RAW message or body]

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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[prev in list] [next in list] [prev in thread] [next in thread]