From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A31CAC0033 for ; Thu, 28 Jul 2022 15:36:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 6CC2E605A3 for ; Thu, 28 Jul 2022 15:36:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6CC2E605A3 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=wuille.net header.i=@wuille.net header.a=rsa-sha256 header.s=protonmail2 header.b=w04woVxi X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 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_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqK0vsGBLSup for ; Thu, 28 Jul 2022 15:36:43 +0000 (UTC) X-Greylist: delayed 00:09:23 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2864460F66 Received: from mail-4321.protonmail.ch (mail-4321.protonmail.ch [185.70.43.21]) by smtp3.osuosl.org (Postfix) with ESMTPS id 2864460F66 for ; Thu, 28 Jul 2022 15:36:41 +0000 (UTC) Date: Thu, 28 Jul 2022 15:27:05 +0000 Authentication-Results: mail-4321.protonmail.ch; dkim=pass (2048-bit key) header.d=wuille.net header.i=@wuille.net header.b="w04woVxi" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail2; t=1659022036; x=1659281236; bh=gOArorsqvqHHecmG/3J1R2HdoIZB1QFWkprEUJY2D1Q=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=w04woVxicbMxMkEopkWmlZQt9qJ+9KMjHmWr3Qb5R0gmtUgXMsLuDfoj0gS1WAjFi LH64HHNsvBZp7p6wGZK8mp89W0ANL7XC5oXUGDZx0NYA5b1IthMHf0jjfd5EJhIms6 J9CuGDT8ptJ0mK2Ad1RwvIOdOWdjm4X21MYTkwVuglpxBo+VhKGoG5OYoXT4LYljPQ v878aGHGifXMQ6jCi3ss2vePHh7cX8o6dsJfZWv1HebzDgNOYFKKYuWIRPBnGePRTM nwjoygtc1OsInnWqVUzL65TOHvWfgLYvEo1ECEvN/qJiIdjrbL+U20dMShFSI8aGYd KgaoXycoJvJIg== To: Ali Sherief , Bitcoin Protocol Discussion From: Pieter Wuille Reply-To: Pieter Wuille Message-ID: In-Reply-To: References: Feedback-ID: 19463299: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:39:22 +0000 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:36:45 -0000 ------- Original Message ------- On Thursday, July 28th, 2022 at 3:27 AM, Ali Sherief via bitcoin-dev wrote: > Essentially, zero-knowledge proofs such as Schnorr are not compatible wit= h address message signing - the public key cannot be retrieved from the add= ress or the signature, so the address does not actually prove the authentic= ity of a Schnorr signature. That's why the public key is required as an inp= ut in the first place. Yes, that's an intentional design choice in BIP340, see note 5: https://git= hub.com/bitcoin/bips/blob/master/bip-0340.mediawiki#cite_ref-5-0. The choic= e is either batch verifiability or public key recovery. I regret ever using public key recovery when introducing the old legacy mes= sage signing scheme. It should just have used script signatures like BIP322= proposes. > In order to make it compatible with the address signing mechanism, the ze= ro-knowledge part would have to be sacrificed in my BIP, or else a complete= ly 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 whic= h 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 solutio= n in my opinion: not restricted to single-key policies, compatible with eve= ry script type, and trivially extensible to future schemes. > , just like BIP340). How so? Every taproot compatible wallet has a BIP340 implementation. Cheers, -- Pieter