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
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <ali@notatether.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9F734C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Aug 2022 04:06:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 6339C41CCE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Aug 2022 04:06:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6339C41CCE
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=I/g7uVgw
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 7jNxjkZ-Aijl
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Aug 2022 04:06:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1989241CCA
Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17])
by smtp4.osuosl.org (Postfix) with ESMTPS id 1989241CCA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Aug 2022 04:06:09 +0000 (UTC)
Date: Fri, 05 Aug 2022 04:05:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
s=protonmail; t=1659672366; x=1659931566;
bh=E6jd5P8jSL50HVdryzCwuzST5rDgROBhqHcL77YuTcM=;
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=I/g7uVgwm40oXoAXQ2zD24Rl+jPjkSBfuEyxLDCBHw7V58iV30izhfKXfLictbrH/
8oGnyDlfGzzBL7uc4cuojeb2YK7ox4F/JPj4mSdnQT/SA9atG0DUJnh/eBj41KZOZn
qsPqJF0zia4RINyRNp8DksAEO+mY7uWSU/Rufl7verMCssPZ/SSd9qCoAoaOZ275aL
QBi7BrjXNh5hpjq3bYYBXJ/OY2ZGqkELQEsnlWlYUU1wziPJNOx5uAvrly2DoWDn1j
NtgFFY6VQ9Woe+f/JhI9z3Vo2qeQuorS2keiKFjDy/Lqek6DNuyCMJDTcayT4yBXt2
XNj4HTKocxWBw==
To: Luke Dashjr <luke@dashjr.org>
From: Ali Sherief <ali@notatether.com>
Reply-To: Ali Sherief <ali@notatether.com>
Message-ID: <oqwpWAHa9lo-RuyC8iwnUDDMmMmQjM3i3a2wuXkN0t3GeoGdTnHoHPH90_KkaVsogyrn2hTFbUN6XKR364K3jOnplsBoKW2AaWJZfBKBqz4=@notatether.com>
In-Reply-To: <202208041926.37309.luke@dashjr.org>
References: <4Lz70s3l79z4x2h7@mail-41103.protonmail.ch>
<20220804121851.7e4zoqxaaolseazn@artanis>
<202208041926.37309.luke@dashjr.org>
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: Fri, 05 Aug 2022 08:51:31 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP-notatether-signedmessage
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: Fri, 05 Aug 2022 04:06:13 -0000
Yeah, I have a specific reason to advance this first (emphasis on the word =
first).
I briefly mentioned in the BIP that BIP322 has superior message verificatio=
n capabilities. This is true, but it suffers from the drawback that wallets=
are not using it. What they are using right now is a chaotic mixture of le=
gacy address sign/verify and nonstandard segwit sign/verify. Attempting to =
enforce BIP322 on them in this stage will just create an N+1 problem, so an=
effort has to be made first to transfer these N signing implementations to=
a common ground, with as little as possible developer effort - it takes mu=
ch less time to code the point-by-point steps than designing a class for BI=
P322 signatures, since the teams behind these wallets have to *agree* on ho=
w to code such a change. This ultimately decides whether or not the wallets=
implement such features as BIP322 or this BIP. [this paragraph is the meat=
of the reasoning.]
That is to say, BIP322 is more complex than this BIP (which in no way repla=
ces BIP322), hence it requires a larger design effort on the part of wallet=
developers to implement. Considering that the vast majority of them alread=
y sign messages using the current format, it makes complete sense to make t=
hem all conform to this BIP first, then we finish BIP322, and then make wal=
lets use that.
Message signatures are highly relied upon in some places (just to name a fe=
w, at many mining pools e.g. Slushpool, and the Bitcointalk forum), and it =
is unreasonable to expect users to cling on to an old address format, or us=
e a specific wallet (Electrum) that provides nonstandard signature verifica=
tion (it does *not* follow BIP137 despite supporting segwit messages, so th=
eir signatures are non-portable).
That is why it is necessary at the present moment to ensure as many wallets=
are possible are not only using the specification in my BIP to perform mes=
sage signing and verification, but also implement, at a bare minimum, the l=
egacy and segwit address parts. And the reason I did not mandate this requi=
rement is the BIP is that wallets do not provide legacy addresses, then it =
makes no sense for them to add the sign/verify code for legacy addresses as=
well.
This BIP is kind of like a "bumper car", in that it forces compliance with =
previous BIPs that extend the message signing format, in particular BIP137.=
I admit that the Taproot signature format should not be located inside thi=
s BIP - I want to keep it strictly Informational, but rather, it should be =
contained in a newer Standards Track BIP that supersedes BIP137 - it's only=
task is to define everything BIP137 already defines, and also add the Tap=
root signing format.
Like I said in the BIP, just making a proposal will not solve all these pro=
blems. It will only solve half of them, and the other half has to be solved=
by getting the other wallet implementations (Armory, Wasabi, BitcoinJ, Sam=
ourai, Mycelium, Electrum, and Trezor/Ledger among others) to implement thi=
s standard. It is not a difficult task but it's a non-trivial one, and we o=
ught to be at least half-way to the finish line by assigning a number to th=
is.
- Ali
------- Original Message -------
On Thursday, August 4th, 2022 at 10:26 PM, Luke Dashjr <luke@dashjr.org> wr=
ote:
> Any reason not to just help Kalle out with BIP 322?
>
> https://github.com/bitcoin/bips/pull/1347
>
>
> On Thursday 04 August 2022 12:18:56 Ali Sherief via bitcoin-dev wrote:
>
> > Hi,
> >
> > I have created a new BIP, called notatether-signedmessage. It can be vi=
ewed
> > at
> > https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedme=
ssag
> > e.mediawiki.
> >
> > For those who want a quick summary, it defines a step-by-step process f=
or
> > signing and verifying messages from legacy, native/nested segwit, and
> > taproot addresses. It does not define a new signature format itself, ex=
cept
> > in the case of Taproot. For those addresses, I have defined a signature
> > format that has 1 byte header/recID, 64 bytes signature, and 32 bytes x
> > coordinate of a public key. This is required to run the BIP340 Schnorr
> > verify algorithm using only the signature - and the header byte is adde=
d
> > for backwards compatibility. Otherwise, it completely integrates BIP137
> > signatures.
> >
> > I am planning to move that format to its own BIP as soon as possible, i=
n
> > lieu that it is unacceptable to define formats in an Informational BIP.
> >
> > Please leave your comments in this mailing list. CC'ing BIP editors.
> >
> > - Ali
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|