📅 Original date posted:2022-04-28
📝 Original message: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
Jonas Nick [ARCHIVE] /
npub1at…y3z5a
2023-06-07 23:07:00
in reply to nevent1q…sx2a
Author Public Key
npub1at3pav59gkeqz9kegzqhk2v4j4r435x42ytf23pxs8crt74tuc8s2y3z5aPublished at
2023-06-07 23:07:00Event JSON
{
"id": "58c383f1ce4db0dca3e6b01c85efec7e8d5c5237b566963c6c83ab773f2ab143",
"pubkey": "eae21eb28545b20116d940817b2995954758d0d5511695442681f035faabe60f",
"created_at": 1686179220,
"kind": 1,
"tags": [
[
"e",
"0fbbc195d6e5b7be2ad759bd8f983f0929dd96c0607600ff40fb47d4236f4a44",
"",
"root"
],
[
"e",
"59f983935765db2f87efa58b4e338727ad7a2eec50a9835887d6a1c9ca96bfa5",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2022-04-28\n📝 Original message:Happy to hear that the BIP draft is already useful and thank you, Laolu, for\nextracting the test vectors.\n\n \u003e an implementation must make the _pre tweaked_ combined key available to the caller\n\nTo apply the Taproot tweak with the key aggregation algorithm as specified you\nwould have to do the following (slightly simplified):\n\nP := KeyAgg(pk_1, ..., pk_n, tweaks = [])\nt := hash_TapTweak(P, root)\nQ := KeyAgg(pk_1, ..., pk_n, tweaks = [t])\n\nThis unnecessarily recomputes the pre-tweaked key aggregate. In the BIP, there\nare more places where the specified algorithms unnecessarily recompute certain\nvalues. I believe this is justified if it makes the spec significantly easier to\nunderstand. In this case, however, it's clear that calling KeyAgg multiple times\nfor the same set of public keys is not intuitive at all. This is something I had\nnot fully considered before. Thanks for bringing it up.\n\nThe approach you're taking in btcd makes a lot of sense to me. But in the\nspecification, we want to avoid specifying how exactly the tweaks are derived.\nIn the libsecp256k1-zkp implementation, key aggregation and tweaking are\nseparated into different functions. But this requires keeping state between key\naggregation and tweaking, which is why we had not chosen this approach for the\nBIP. I will investigate how in the BIP, we can also split key aggregation and\ntweaking and minimize complexity.\n\n \u003e My reading here is that [...] last party doesn't (?) need to worry about their\n \u003e nonces\n\nYour reading is mostly right. Brandon describes correctly how and why to modify\nthe nonce generation algorithm. I opened a PR that replaces the description of\nthis signing mode with a precise specification. Indeed, the result is that the\nlast party doesn't need to worry about their nonce (even if the other parties\nuse bad randomness).\n\n[0] https://github.com/jonasnick/bips/pull/11",
"sig": "1d82053eaef9a40285fffad71be5606fee7b825e6ec44c16f9aa2da9c426607c92c6965cab5145832170df7f00998b2ea0baef457e5fc47df2ab32a3d2518c63"
}