Date: Thu, 28 Jul 2022 15:51:18 +0000
To: Pieter Wuille <bitcoin-dev@wuille.net>
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <ltMy8y1N-J_DQ0rQiKcb1fkiBkd9PcLX6B4W_TZ6i7bdmNWQMXJ0h2fet6DFKvllyH0QNzzVnqMpxT3vMgxdwJKOfsUKf8lS5P5sTC4-3j8=@notatether.com>
In-Reply-To: <BQZI2zpZwzJcXi_Gxr0f1wg9ZD6U5nb0HTOfIu4i50nM6FqFNqFjfm4DbOIxg94IwZQ4pHAthUNeGUkwHENJwAhap-bIkuKRN8ErZyFeR-o=@wuille.net>
References: <bG2Fk0bM_4lbwijBwZRiGgCAmktVOFSY5vR5k1D7QSc8imn9NWXxfOLPgMl5p22vfAPDHeuEA_p6TDhU7qGFoVmZok57RzA9rEV1LJzHpsM=@notatether.com>
 <BQZI2zpZwzJcXi_Gxr0f1wg9ZD6U5nb0HTOfIu4i50nM6FqFNqFjfm4DbOIxg94IwZQ4pHAthUNeGUkwHENJwAhap-bIkuKRN8ErZyFeR-o=@wuille.net>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Zero-knowledge proofs e.g. Schnorr are
	incompatible with address signing without compromise
Precedence: list

> Yes, that's an intentional design choice in BIP340, see note 5: https://g=
ithub.com/bitcoin/bips/blob/master/bip-0340.mediawiki#cite_ref-5-0. The cho=
ice is either batch verifiability or public key recovery.

The way I understood the BIP, was that a user can do batch recovery or sing=
le-key recovery. Can you explain how it is possible to recover a public key=
 from a single-key signature, because a few days earlier on the BIP-notatet=
her-messageverify thread I was told (I think it was achow) that Schnorr doe=
sn't allow for public key recovery.

At any case, I was already planning on just concatenating the public key af=
ter the signature (the other option I was thinking of, appending it after t=
he Taproot address, is quite unruly in my opinion).

> I think it would be much better if people would cooperate to get BIP322 t=
o move forward than to keep inventing other formats. It's the obvious solut=
ion in my opinion: not restricted to single-key policies, compatible with e=
very script type, and trivially extensible to future schemes.

This is why I especially tried to avoid making a new format - My BIP is str=
ictly an Informational one. That strategy worked pretty well up to now, but=
 now I find myself forced to make a small concession in the design to suppo=
rt the verification of Taproot address. But I'm glad it's quite trivial as =
appending a single variable. So at least this BIP won't be an obstacle to a=
ny such effort.

[Besides, since I'm also planning on detecting BIP137 in the verification m=
ethods, I can assume the Signature field contains arbitrary data.]

> > , just like BIP340).
>
>
> How so? Every taproot compatible wallet has a BIP340 implementation.

I guess I made an assumption, since almost all of the wallets I have seen d=
id not have a sign message feature, not even for legacy addresses.

- Ali

------- Original Message -------
On Thursday, July 28th, 2022 at 3:27 PM, Pieter Wuille <bitcoin-dev@wuille.=
net> wrote:


> ------- Original Message -------
> On Thursday, July 28th, 2022 at 3:27 AM, Ali Sherief via bitcoin-dev bitc=
oin-dev@lists.linuxfoundation.org wrote:
>
> > Essentially, zero-knowledge proofs such as Schnorr are not compatible w=
ith address message signing - the public key cannot be retrieved from the a=
ddress or the signature, so the address does not actually prove the authent=
icity of a Schnorr signature. That's why the public key is required as an i=
nput in the first place.
>
>
> Yes, that's an intentional design choice in BIP340, see note 5: https://g=
ithub.com/bitcoin/bips/blob/master/bip-0340.mediawiki#cite_ref-5-0. The cho=
ice is either batch verifiability or public key recovery.
>
> I regret ever using public key recovery when introducing the old legacy m=
essage signing scheme. It should just have used script signatures like BIP3=
22 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 comple=
tely 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 wh=
ich can verify anything and everything, but nobody is implementing that
>
>
> I think it would be much better if people would cooperate to get BIP322 t=
o move forward than to keep inventing other formats. It's the obvious solut=
ion in my opinion: not restricted to single-key policies, compatible with e=
very script type, and trivially extensible to future schemes.
>
> > , just like BIP340).
>
>
> How so? Every taproot compatible wallet has a BIP340 implementation.
>
> Cheers,
>
> --
> Pieter