1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Return-Path: <ali@notatether.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B467CC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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
X-Mailman-Approved-At: Thu, 28 Jul 2022 15:54:45 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
|
