Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B467CC002D for ; Thu, 28 Jul 2022 15:51:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 7F8024198B for ; Thu, 28 Jul 2022 15:51:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7F8024198B Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=notatether.com header.i=@notatether.com header.a=rsa-sha256 header.s=protonmail header.b=JlSm64of X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_OBFU_SUBJ=1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEP9RR-RkFs5 for ; Thu, 28 Jul 2022 15:51:26 +0000 (UTC) X-Greylist: delayed 08:24:12 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 812AE417D2 Received: from mail-4018.proton.ch (mail-4018.proton.ch [185.70.40.18]) by smtp4.osuosl.org (Postfix) with ESMTPS id 812AE417D2 for ; Thu, 28 Jul 2022 15:51:25 +0000 (UTC) Date: Thu, 28 Jul 2022 15:51:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com; s=protonmail; t=1659023482; x=1659282682; bh=eM4ixyYLRhx9niqsOp9fiPpB4ag6uJSgLOiL2XDdTng=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=JlSm64of7znGY3FPBDSIqAVpZ5l1OqIXAc1bGvQW++7siNM+siaiPev/8jRoU6D+h NyVyfWjysGgcG+Li7DAymndJq4RZUSQfO8h1y8nestEyzS2TQaBYb37Yur7SP6o+nx s0+86TYxYdo/LjgW1J0Ey6jbq1fjAOhkYyw5Z9B5gk7Qb1ZcInpTyu0D0KtTmWs4+i v/tnIUnLUWsTRigPmSaQEj57B34G4eQ1u/UfSY2s2ry+unxz6DaJ9N1s8ZfcWfDbzQ ty3MMZLjKApJOXf6c3gUsYNjYncjXFIWtC2pxJKZ4m3T058HPFcjWUdmvsr7AW/z2E hwg86tKYgzyWQ== To: Pieter Wuille From: Ali Sherief Reply-To: Ali Sherief Message-ID: In-Reply-To: References: Feedback-ID: 34210769:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 28 Jul 2022 15:54:45 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Zero-knowledge proofs e.g. Schnorr are incompatible with address signing without compromise X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2022 15:51:27 -0000 > 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 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