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
