📅 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
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-08 01:12:19
in reply to nevent1q…0y5k
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-08 01:12:19Event JSON
{
"id": "87433ffb5fadf94991f7f5edf43593fa40f4c67caef44488e34649c9418b2ea2",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686179539,
"kind": 1,
"tags": [
[
"e",
"3ef89fc35bc86af7b753ea38edb228d7daafc356598549754d0b95c45ae9b62a",
"",
"root"
],
[
"e",
"485d847f2ab4d00332d913a47718d57bac4f3845cc6e9d02efb620dd26d1c518",
"",
"reply"
],
[
"p",
"300ba94cc910da0a8903ca9e40487283545661c726c81fd5942e11a0683ad617"
]
],
"content": "📅 Original date posted:2022-07-28\n📝 Original message:------- Original Message -------\nOn Thursday, July 28th, 2022 at 3:27 AM, Ali Sherief via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e 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.\n\nYes, 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.\n\nI regret ever using public key recovery when introducing the old legacy message signing scheme. It should just have used script signatures like BIP322 proposes.\n\n\u003e 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\n\nYou can avoid relying on public key recovery, and include the public key + BIP340 signature in the encoded signature.\n\n\u003e (which, in my view, is redundant - there is already the draft BIP322 which can verify anything and everything, but nobody is implementing that\n\nI 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.\n\n\u003e , just like BIP340).\n\nHow so? Every taproot compatible wallet has a BIP340 implementation.\n\nCheers,\n\n--\nPieter",
"sig": "22e4cc7435443cffda4e95d9e8aa85733b8cc4b8e643005de71c4891efcb4f257b660961eac7187a47dba32208e24534ccac57e521beeaad97e8f01e34037c55"
}