Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-28 📝 Original message:------- Original Message ...
📅 Original date posted:2022-07-28
📝 Original message:------- Original Message -------
On Thursday, July 28th, 2022 at 3:27 AM, Ali Sherief via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Essentially, zero-knowledge proofs such as Schnorr are not compatible with address message signing - the public key cannot be retrieved from the address or the signature, so the address does not actually prove the authenticity of a Schnorr signature. That's why the public key is required as an input in the first place.
Yes, that's an intentional design choice in BIP340, see note 5: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#cite_ref-5-0. The choice is either batch verifiability or public key recovery.
I regret ever using public key recovery when introducing the old legacy message signing scheme. It should just have used script signatures like BIP322 proposes.
> In order to make it compatible with the address signing mechanism, the zero-knowledge part would have to be sacrificed in my BIP, or else a completely separate message signing format just for Taproot would be required
You can avoid relying on public key recovery, and include the public key + BIP340 signature in the encoded signature.
> (which, in my view, is redundant - there is already the draft BIP322 which can verify anything and everything, but nobody is implementing that
I think it would be much better if people would cooperate to get BIP322 to move forward than to keep inventing other formats. It's the obvious solution in my opinion: not restricted to single-key policies, compatible with every script type, and trivially extensible to future schemes.
> , just like BIP340).
How so? Every taproot compatible wallet has a BIP340 implementation.
Cheers,
--
Pieter
📝 Original message:------- Original Message -------
On Thursday, July 28th, 2022 at 3:27 AM, Ali Sherief via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Essentially, zero-knowledge proofs such as Schnorr are not compatible with address message signing - the public key cannot be retrieved from the address or the signature, so the address does not actually prove the authenticity of a Schnorr signature. That's why the public key is required as an input in the first place.
Yes, that's an intentional design choice in BIP340, see note 5: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#cite_ref-5-0. The choice is either batch verifiability or public key recovery.
I regret ever using public key recovery when introducing the old legacy message signing scheme. It should just have used script signatures like BIP322 proposes.
> In order to make it compatible with the address signing mechanism, the zero-knowledge part would have to be sacrificed in my BIP, or else a completely separate message signing format just for Taproot would be required
You can avoid relying on public key recovery, and include the public key + BIP340 signature in the encoded signature.
> (which, in my view, is redundant - there is already the draft BIP322 which can verify anything and everything, but nobody is implementing that
I think it would be much better if people would cooperate to get BIP322 to move forward than to keep inventing other formats. It's the obvious solution in my opinion: not restricted to single-key policies, compatible with every script type, and trivially extensible to future schemes.
> , just like BIP340).
How so? Every taproot compatible wallet has a BIP340 implementation.
Cheers,
--
Pieter