------- Original Message ------- On Thursday, July 28th, 2022 at 3:27 AM, Ali Sherief via bitcoin-dev <bitcoin-dev@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
