‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, February 11, 2021 6:38 AM, Dr Maxim Orlovsky <orlov...@protonmail.com> wrote:
> 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. The only thing ECDSA/Schnorr specific about this is that - if you want to maintain provable security - the keys used for ECDSA and BIP340 should be separated by a hardened step. It seems however that all approaches people actually use to prevent reuse do that already. 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. 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. Greg Maxwell pointed out to me that there may be another reason to want non-reuse across ECDSA and BIP340 keys: if someone were to do all of these wrong: * not follow BIP340 and re-use RFC6979 for BIP340 nonce generation * reuse the same keys for both * sign the same message with both ... you would actually leak your private key. This isn't a concern for Bitcoin transaction signing however, as the sighash (message) indirectly commits to BIP341 or not, and thus it'd be impossible to construct colliding messages. Still, it's a consideration to factor in. Cheers, -- Pieter _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
