📅 Original date posted:2021-02-18
📝 Original message:Hi Pieter,
Addressing your comments:
>> Thank you very much for all the clarifications; it’s good to have them sorted out and clearly structured. From what you wrote it follows that we still need to reserve a dedicated purpose (with new BIP) for BIP340 signatures to avoid key reuse, am I right?
>
> Maybe, but it would be for a particular way of using keys (presumably: single-key pay-to-taproot), not just the signature scheme itself. If you go down this path you'll also want dedicated branches for multisig participation, and presumably several interesting new policies that become possible with Taproot.
Yes, previously we had a dedicated standards (BIPs) for purpose fields on each variant: single-sig, multi-sig etc. With this proposal I simplify this: you will have a dedicated deterministically-derived *hardened* keys for each use case under single standard, which should simplify future wallet implementations.
> And as I said, dedicated branches only help for the simple case. For example, it doesn't address the more general problem of preventing reuse of keys in multiple distinct groups of multisig sets you participate in. If you want to solve that you need to keep track of index is for participating in what - and once you have something like that you don't need dedicated purpose based derivation at all anymore.
In the BIP proposal there is a part on how multisigs can be created in a simple and deterministic way without keys reuse.
> So I'm not sure I'd state it as us *needing* a dedicated purpose/branch for single-key P2TR (and probably many other useful ways of using taproot based spending policies...). But perhaps it's useful to have.
My proposal is to have a new purpose field supporting all the above: hardened derivation that supports for multisigs, single-sigs etc.
Kind regards,
Maxim
Dr Maxim Orlovsky [ARCHIVE] /
npub1a8…rpwgy
2023-06-07 18:28:29
in reply to nevent1q…cggs
Author Public Key
npub1a80jcetgws9xmu7wnylvekpymw2acym2psjpp03e0chmhq38pc8qwrpwgyPublished at
2023-06-07 18:28:29Event JSON
{
"id": "60f8860bf415d56656cec38896b3583caa287e623ab1dd22301f087554104222",
"pubkey": "e9df2c6568740a6df3ce993eccd824db95dc136a0c2410be397e2fbb82270e0e",
"created_at": 1686162509,
"kind": 1,
"tags": [
[
"e",
"d2c8b65efdaee73f5c5fd62fe4b915d4fcf718277dfab7951f3a1bbc122c404e",
"",
"root"
],
[
"e",
"a1201b08a41d43b79759962b8e7a6506a476907de46665ba34ad81e356e87eb8",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2021-02-18\n📝 Original message:Hi Pieter,\n\nAddressing your comments:\n\n\u003e\u003e Thank you very much for all the clarifications; it’s good to have them sorted out and clearly structured. From what you wrote it follows that we still need to reserve a dedicated purpose (with new BIP) for BIP340 signatures to avoid key reuse, am I right?\n\u003e \n\u003e Maybe, but it would be for a particular way of using keys (presumably: single-key pay-to-taproot), not just the signature scheme itself. If you go down this path you'll also want dedicated branches for multisig participation, and presumably several interesting new policies that become possible with Taproot.\n\nYes, previously we had a dedicated standards (BIPs) for purpose fields on each variant: single-sig, multi-sig etc. With this proposal I simplify this: you will have a dedicated deterministically-derived *hardened* keys for each use case under single standard, which should simplify future wallet implementations.\n\n\n\u003e And as I said, dedicated branches only help for the simple case. For example, it doesn't address the more general problem of preventing reuse of keys in multiple distinct groups of multisig sets you participate in. If you want to solve that you need to keep track of index is for participating in what - and once you have something like that you don't need dedicated purpose based derivation at all anymore.\n\nIn the BIP proposal there is a part on how multisigs can be created in a simple and deterministic way without keys reuse.\n\n\n\u003e So I'm not sure I'd state it as us *needing* a dedicated purpose/branch for single-key P2TR (and probably many other useful ways of using taproot based spending policies...). But perhaps it's useful to have.\n\nMy proposal is to have a new purpose field supporting all the above: hardened derivation that supports for multisigs, single-sigs etc.\n\n\nKind regards,\nMaxim",
"sig": "47498615d5f3d00513a7736620d649996d16f4ee14c44ad1930c6e7edf92577642a5f255866ac2018dac28196a9d372a84369204b4c133e7610b1df666c58a06"
}