From: Dr Maxim Orlovsky <orlovsky@protonmail•com>
To: Pieter Wuille <bitcoin-dev@wuille•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity
Date: Thu, 18 Feb 2021 18:58:54 +0000 [thread overview]
Message-ID: <B51720B9-1BC4-4679-AA67-A1DE5687B89A@protonmail.com> (raw)
In-Reply-To: <AzQAiClGFEDDux7hDtaD3As76nWOJELk9eck-_Ra4lDTwXQz2lYJEwRHjq9Gt65cA7AgKbidpNQlD-U6g5OKM-EaNvPbgva-ASzt-LcBDT8=@wuille.net>
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
next prev parent reply other threads:[~2021-02-18 18:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-05 17:51 Dr Maxim Orlovsky
2021-02-05 22:00 ` Dmitry Petukhov
2021-02-11 7:27 ` Dr Maxim Orlovsky
2021-02-05 22:37 ` Christopher Allen
2021-02-11 7:28 ` Dr Maxim Orlovsky
2021-02-06 1:15 ` Pieter Wuille
2021-02-11 14:38 ` Dr Maxim Orlovsky
2021-02-11 20:31 ` Pieter Wuille
2021-02-18 18:58 ` Dr Maxim Orlovsky [this message]
[not found] ` <CALqxMTG1MG+PvLfSLRqsa_yHBQOdu7BOqBjm4_ShSsB3CNSCOA@mail.gmail.com>
2021-02-18 18:52 ` Dr Maxim Orlovsky
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=B51720B9-1BC4-4679-AA67-A1DE5687B89A@protonmail.com \
--to=orlovsky@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@wuille$(echo .)net \
/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