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
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A9F6F11C0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 26 Mar 2018 08:53:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f174.google.com (mail-ot0-f174.google.com
[74.125.82.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C91F55D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 26 Mar 2018 08:53:24 +0000 (UTC)
Received: by mail-ot0-f174.google.com with SMTP id m7-v6so19795381otd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 26 Mar 2018 01:53:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=YAEHCH95I8GECMpPeDvIroo2vN3sYJjA9jdtLe9lvjk=;
b=BQaEyk3zGJX2pwPcahA2unzGsWeBusom+401ME4UTveL1ggBDE/cu/wo/qJxtWNtNE
xHgUmuzc5AMutEapfl9aKOY059FA+GgjH1xK4Vm2MNbbZM39VznWZQ8G8Emaq+kXylvA
AGofU4i/7lm4yoxdI+2SNaisFsfB0wPcn4ZSLcfFVYMjYmbRDrHZWIESXN5MoAOneJ8V
kJQcVHkZnCIxQ8aGlMSZg7Hkq9DIxnAG9upmKbgSXSBLxcOPw3c3vJg7ujZ52EmQU1sp
On8h6OrEh7Ut+6CrUSAhtiV2ha4U2aCtQGGDnFwXkDUIWfx9tJoypf/USfeiKn73sRC7
EmlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=YAEHCH95I8GECMpPeDvIroo2vN3sYJjA9jdtLe9lvjk=;
b=BoHndj6JISl9YSirWoCXoHTohz+8iGw7e6pwNBuMhbtk2pTQEWJIdEoybUTgiIMQTE
xXjSeZANr16ABAUa8m1ND+gm/tNbHMAZb7p0M08doYI+03C3BGjKw2JCS3qwOCXuNP4t
6rZMl9PySXg8E2CJPnu2WHwZmoyh8odEm6BEf5IewOXg1gzVQp7owikhbCztCdk88uE1
xWnAfo1PrOx3RU4PqDmmpCdq0tOGd3M9dy4R1Q0zwTJ7J8d9a9w66NUOOo5Hwk3kHfCp
5c7jWEUU+QrpOhKqlZYReFh6ytl3jaKR+G6ZmmRzMtfrMWVPnWu9bF+C0OEsnNSkSObH
3Wbg==
X-Gm-Message-State: AElRT7Gws4c9RXT1YaW5JZbwhIKBcmZSGaRWFU4VsscW06/dl+OgDDYN
sweuzTJRzC9juiUGgfFNXHLpJE+74A7U5HoyyhQ=
X-Google-Smtp-Source: AIpwx49mOtFO4pshAgUIb6yRJLi2CoSjSFllKus6D8JumxpM6ZT/y0omZaGrgQOuJ7xyeF/0+Eblf44QWUNtIjW8eMw=
X-Received: by 2002:a9d:550b:: with SMTP id
l11-v6mr5953282oth.356.1522054403848;
Mon, 26 Mar 2018 01:53:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.106.135 with HTTP; Mon, 26 Mar 2018 01:53:23 -0700 (PDT)
In-Reply-To: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
References: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Mon, 26 Mar 2018 01:53:23 -0700
Message-ID: <CAPg+sBhAaw7uqdz6ZoMCkut2GM=3=F22FiHw6J_aLwTMEcqt1g@mail.gmail.com>
To: Karl Johan Alm <karljohan-alm@garage.co.jp>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001201bd05684ce8f6"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] {sign|verify}message replacement
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Mon, 26 Mar 2018 08:53:25 -0000
--0000000000001201bd05684ce8f6
Content-Type: text/plain; charset="UTF-8"
Hello,
Thanks for starting a discussion about this idea.
A few comments inline:
On Wed, Mar 14, 2018 at 1:09 AM, Karl Johan Alm via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello,
>
> I am considering writing a replacement for the message signing tools
> that are currently broken for all but the legacy 1xx addresses. The
> approach (suggested by Pieter Wuille) is to do a script based
> approach. This does not seem to require a lot of effort for
> implementing in Bitcoin Core*. Below is my proposal for this system:
>
> A new structure SignatureProof is added, which is a simple scriptSig &
> witnessProgram container that can be serialized. This is passed out
> from/into the signer/verifier.
>
You need a bit more logic to deal with softforks and compatibility. The
question is which script validation flags you verify with:
* If you make them fixed, it means signatures can't evolve with new address
types being introduced that rely on new features.
* If you make it just consensus flags (following mainnet), it means that
people with old software will see future invalid signatures as always
valid; this is probably not acceptable.
* If you make it standardness flags, you will get future valid signatures
that fail to verify.
One solution is to include a version number in the signature, which
explicitly corresponds to a set of validation flags. When the version
number is something a verifier doesn't know, it can be reported as
inconclusive (it's relying on features you don't know about).
An solution is to verify twice; once with all consensus rules you know
about, and once with standardness rules. If they're both valid, the
signature is valid. If they're both invalid, the signature is invalid. If
they're different (consensus valid but standardness invalid), you report
the signature validation as inconclusive (it's relying on features you
don't know about). This approach works as long as new features only use
previous standardness-invalid scripts, but perhaps a version number is
still needed to indicate the standardness flags.
RPC commands:
>
> sign <address> <message> [<prehashed>=false]
>
Why not extend the existing signmessage/verifymessage RPC? For legacy
addresses it can fall back to the existing signature algorithm, while using
the script-based approach for all others.
>
> Generates a signature proof for <message> using the same method that
> would be used to spend coins sent to <address>.**
>
> verify <address> <message> <proof> [<prehashed>=false]
>
> Deserializes and executes the proof using a custom signature checker
> whose sighash is derived from <message>. Returns true if the check
> succeeds, and false otherwise. The scriptPubKey is derived directly
> from <address>.**
>
> Feedback welcome.
>
> -Kalle.
>
>
(**) If <prehashed> is true, <message> is the sighash, otherwise
> sighash=sha256d(message).
>
That's very dangerous I'm afraid. It could be used to trick someone into
signing off on an actual transaction, if you get them to sign a "random
looking" prehashed message. Even if you have a prehashed message, there is
no problem with treating it as hex input to a second hashing step, so I
think the prehashed option isn't needed. It's why the existing message
signing functionality always forcibly prefixes "Bitcoin signed message:",
to avoid signing something that unintentionally corresponds to a message
intended for another goal.
Cheers,
--
Pieter
--0000000000001201bd05684ce8f6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello,<br><br>Thanks for starting a discussion about this =
idea.<br><br>A few comments inline:<br><br>On Wed, Mar 14, 2018 at 1:09 AM,=
Karl Johan Alm via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin=
uxfoundation.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I am considering writing a replacement for the message signing tools<br>
that are currently broken for all but the legacy 1xx addresses. The<br>
approach (suggested by Pieter Wuille) is to do a script based<br>
approach. This does not seem to require a lot of effort for<br>
implementing in Bitcoin Core*. Below is my proposal for this system:<br>
<br>
A new structure SignatureProof is added, which is a simple scriptSig &<=
br>
witnessProgram container that can be serialized. This is passed out<br>
from/into the signer/verifier.<br></blockquote><div><br></div><div>You need=
a bit more logic to deal with softforks and compatibility. The question is=
which script validation flags you verify with:<br></div><div>* If you make=
them fixed, it means signatures can't evolve with new address types be=
ing introduced that rely on new features.<br></div><div>* If you make it ju=
st consensus flags (following mainnet), it means that people with old softw=
are will see future invalid signatures as always valid; this is probably no=
t acceptable.<br></div><div>* If you make it standardness flags, you will g=
et future valid signatures that fail to verify.<br><br></div><div>One solut=
ion is to include a version number in the signature, which explicitly corre=
sponds to a set of validation flags. When the version number is something a=
verifier doesn't know, it can be reported as inconclusive (it's re=
lying on features you don't know about). <br><br></div><div>An solution=
is to verify twice; once with all consensus rules you know about, and once=
with standardness rules. If they're both valid, the signature is valid=
. If they're both invalid, the signature is invalid. If they're dif=
ferent (consensus valid but standardness invalid), you report the signature=
validation as inconclusive (it's relying on features you don't kno=
w about). This approach works as long as new features only use previous sta=
ndardness-invalid scripts, but perhaps a version number is still needed to =
indicate the standardness flags.<br></div></div><div class=3D"gmail_quote">=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
RPC commands:<br>
<br>
sign <address> <message> [<prehashed>=3Dfalse]<br></block=
quote><div><br></div><div>Why not extend the existing signmessage/verifymes=
sage RPC? For legacy addresses it can fall back to the existing signature a=
lgorithm, while using the script-based approach for all others.<br>=C2=A0<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<br>
Generates a signature proof for <message> using the same method that<=
br>
would be used to spend coins sent to <address>.**<br>
<br>
verify <address> <message> <proof> [<prehashed>=3Df=
alse]<br>
<br>
Deserializes and executes the proof using a custom signature checker<br>
whose sighash is derived from <message>. Returns true if the check<br=
>
succeeds, and false otherwise. The scriptPubKey is derived directly<br>
from <address>.**<br>
<br>
Feedback welcome.<br>
<br>
-Kalle.<br>=C2=A0
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
(**) If <prehashed> is true, <message> is the sighash, otherwis=
e<br>
sighash=3Dsha256d(message).<br></blockquote><div><br></div><div>That's =
very dangerous I'm afraid. It could be used to trick someone into signi=
ng off on an actual transaction, if you get them to sign a "random loo=
king" prehashed message. Even if you have a prehashed message, there i=
s no problem with treating it as hex input to a second hashing step, so I t=
hink the prehashed option isn't needed. It's why the existing messa=
ge signing functionality always forcibly prefixes "Bitcoin signed mess=
age:", to avoid signing something that unintentionally corresponds to =
a message intended for another goal.<br><br></div><div>Cheers,<br><br>-- <b=
r></div><div>Pieter<br>=C2=A0<br></div></div></div></div>
--0000000000001201bd05684ce8f6--
|