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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
Return-Path: <peter@coinkite.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 78914C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 13:36:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 5332660AD4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 13:36:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5332660AD4
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=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 NlJWLad4_AYz
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 13:36:44 +0000 (UTC)
X-Greylist: delayed 00:05:20 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5251E607D1
Received: from smtp72.ord1c.emailsrvr.com (smtp72.ord1c.emailsrvr.com
[108.166.43.72])
by smtp3.osuosl.org (Postfix) with ESMTPS id 5251E607D1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Jul 2022 13:36:44 +0000 (UTC)
X-Auth-ID: peter@coinkite.com
Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender:
peter-AT-coinkite.com) with ESMTPSA id A7EE3C00C4;
Wed, 20 Jul 2022 09:31:22 -0400 (EDT)
Date: Wed, 20 Jul 2022 09:31:21 -0400
From: "Peter (Coinkite Inc)" <peter@coinkite.com>
To: Ali Sherief <ali@notatether.com>
Message-ID: <YtgDqWSIbX8EJc3B@coinkite.com>
Reply-To: Peter <peter@coinkite.com>
References: <7QoRGux2ow375UP6-XXIF6kI_0tbt-RxKrXiyuDBWVWh6Shjia-ShKy_or5FK9u46KkPAvK2biaSe_x8fMWP0Q==@protonmail.internalid>
<mailman.84940.1658205911.8511.bitcoin-dev@lists.linuxfoundation.org>
<20220719104725.ppic7jy4ghfieeap@artanis>
<oe8IgklW6ypj4lPpkHumHi-Y79x0ZQqzxzPVYrRadh3oz0130kKr7Q2TwGp8_wqpvif-B1stIifA_0kOmO3BOZvQMDXisSsLEN17js1z0lY=@notatether.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="xUUxadUa803MdFgj"
Content-Disposition: inline
In-Reply-To: <oe8IgklW6ypj4lPpkHumHi-Y79x0ZQqzxzPVYrRadh3oz0130kKr7Q2TwGp8_wqpvif-B1stIifA_0kOmO3BOZvQMDXisSsLEN17js1z0lY=@notatether.com>
Organization: Coinkite Inc. (coinkite.com)
X-Classification-ID: 37f91285-488c-4b44-a3f6-b01754f86508-1-1
X-Mailman-Approved-At: Wed, 20 Jul 2022 21:46:02 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trying all address types in message signing
verification (BIP)
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: Wed, 20 Jul 2022 13:36:46 -0000
--xUUxadUa803MdFgj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi Ali.
> This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My pro=
posal is simply going to standardize the practice of placing the segwit add=
ress into the address field, and does not require alterations to the messag=
e signing format like those BIPs.
COLDCARD makes signatures exacly like that, when told to sign with a segwit=
address:
% ckcc msg -s Hello
Hello =20
bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5m=
NTWH9qkDoqZTpnPc=3D
Unfortunately, I do not know of any "verifiers" that will accept the above =
signature, but there is no alternative since the various BIP-322 proposals =
never gained wide acceptance.
Bitcoin Core does not support verifying that message, even though the UX ma=
kes it look possible. In effect segwit features never got implemented to th=
at depth in Core. It's sad because the community is not maintaining core (C=
ore?) features to the same depth as Satoshi did when he was active in the p=
roject.
> PS. I am pretty sure that there is a BIP for the original signing method =
- what is its number?
My understanding that the original approach was directly from Satoshi himse=
lf when the original client was written. It has never been codified in a BI=
P as far as I know.
A related issue the the "ascii armor" that is sometimes used. It's a little=
like RFC2440 <https://www.ietf.org/rfc/rfc2440.txt> but newline-treatment =
isn't defined well enough for good interoperability, in my personal experie=
nce.
So in summary... yes a "defacto" BIP is needed and useful to do, in my opin=
ion. Then Core should be updated to support it as well.
---
@DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
On Wed, Jul 20, 2022 at 04:10:09AM +0000, Ali Sherief wrote:
> [my third attempt at getting this message through. Surprisingly, I manage=
d to send this at the second try with the correct SMTP, From, To and all, b=
ut maybe it was caught in GreyListing (protonmail).]
>=20
> I was thinking about creating a BIP to address the lack of standardizatio=
n for Segwit message signatures, but I want some advice before proceeding.
>=20
> The current state of affairs is that the wallets that do support signing =
and verifying a bitcoin message can only sign legacy addresses. It is techn=
ically possible to sign and verify segwit addresses, since ECDSA only depen=
ds on the public key (hence why you need a private key to sign messages).
>=20
> However, because there is no generally-accepted standard for signing segw=
it messages, the wallets that do support this feature simply insert the seg=
wit address into the address field. Verification also only works using the =
procedure on that specific wallet software, if only because the conventiona=
l tools for verifying messages attempt to reconstruct a legacy address only.
>=20
> This BIP is not going to enforce anything, it's just going to set guideli=
nes for writing a message signing and verification procedure.
>=20
> This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My pro=
posal is simply going to standardize the practice of placing the segwit add=
ress into the address field, and does not require alterations to the messag=
e signing format like those BIPs.
>=20
> In summary, in the verification part, the following address hashing algor=
ithms will be tried in sequence in an attempt to reconstruct the address in=
the signed message:
> - P2PKH (legacy address)
> - P2WPKH-P2SH (nested segwit)
> - P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit=
with version 0 as well as future native segwit address types such as Tapro=
ot) - where MAX_WITNESS_VERSION is the maximum supported witness version by=
the bech32 encoding.
>=20
> The verification procedure stops if any of these hashes yield the correct=
address, and fails if all of the above methods fail to reproduce the addre=
ss in the signed message.
>=20
> In the signing procedure, the only modification is the insertion of the s=
egwit address in place of the legacy address in the signed message.
>=20
> If this BIP is approved, it does not require any changes to existing sign=
ed messages, and the original sign/verify algorithms will continue to inter=
operate with this improved sign/verify algorithm, without any action necess=
ary from the developers.
>=20
> So as you can see, this is the entire framework of the BIP I plan to draf=
t. There is no need for any auxilliary feature additions into this BIP. I j=
ust want to hear the mailing list's advice about how I should draft such a =
BIP.
>=20
> - Ali
>=20
> PS. I am pretty sure that there is a BIP for the original signing method =
- what is its number?
>=20
--xUUxadUa803MdFgj
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEERYl3mt/BTzMnU06oo6MbrVoqWxAFAmLYA6kACgkQo6MbrVoq
WxAyhwgAsfRD0zjiuEtwA7tDg+rCrOzzljl3bXJD1sJ9PmgZbTYt5v8bc+4chD/t
Q3KhFyNdWEoNVPPtgI2ExqmPFTFeYXoMbXWU6mth5LE6npc+468cUiutP3jIHM6E
hSQ0bQm/dUAxNrN2G3cLKwkxMspQVxp4Ure+EvjM9be4QTBpM4Z/CMZXjugeaZ+O
HOuSVdaYaWAO7ENJqhsWsRV8DL7IzNc/ho/p4OM63/zLA6DRqnffKG86Kirdvlhf
rBiSrgx1g1NMhUgs3AOJCpzn9Mo1QcwWKYOjx1eXKXlrsh6jJtfL1VhS6/kyHjMl
MeJnvoBCDo6a8pYD9B4mgaBXUnHMYQ==
=Ly4+
-----END PGP SIGNATURE-----
--xUUxadUa803MdFgj--
|
