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
|
Return-Path: <kalle@rosenbaum.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5A55011DC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Mar 2018 09:46:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com
[209.85.213.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A57D85CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Mar 2018 09:46:57 +0000 (UTC)
Received: by mail-vk0-f48.google.com with SMTP id p189so1567427vkd.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Mar 2018 02:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=rosenbaum-se.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=otLWfI8x5bMaCYfx022hPXrverAlsa3za0y3yPl63w8=;
b=O081/x8mmMImA8YcYipEN9L/5FYk4Z2/A4LbpegDXxp7lWmarEo+gqHo4HZCt85opO
ChMvL31XZnL1hQ4VmL6a3jS8+tTZunMIXhts9TqhXluH1AWNGoTsx12XfAaNHUWE8zZ/
SD12pjHAScBasOVVQZ1YdVSDShfaFEC5LfxyCv6RteOiD160gdXasxwcgylyNYOvVp3b
DPQ/DhlF86IgkrKm4I7O7pyClzXo2T+M9CDW9R8pGNSs0XYqOnLasaZrT3djelxt+QuN
MizDBwKc/lxP0P8Ovh93wRyKbMng40ETEZjKjV79aJG/+1uEYU1HqawLMpVrQaZMg3TC
9ZJQ==
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=otLWfI8x5bMaCYfx022hPXrverAlsa3za0y3yPl63w8=;
b=n5/KleotMbIt74fdUrFLGPipwjN+w9RpE0UDIMJa7WDZcCALN6XD7PAhLOy2D+jAD+
7g4/p2aWVfkUfwoef7W17TbkrVRFNNIealUrN4AmrJRJMDaK+SQBdkvGpkosKiJ4C8kA
zimyt6WvQQPaT1py7xKBwk5vtUpN4aoABoTHAWgvlcAw8ZzbisyZBad4F45Dz5PoO/HG
BBTOfHYBB7eZRy7prQHFUKUfzsi3LTB9/kx6RSle8KnF2ijIw2hCw4p0hlp6N7Ed0J6g
YMq4gpSgZLsk5idXPskp45c/G4+Ax7JlNonkV/VgaN3AOGKCdryi0z+SzeiL2BxJxUwW
dh+g==
X-Gm-Message-State: AElRT7Hr4xfQjwzI8Vt1HSJOa0xvut+F/xsPxMHuxpoAK9o8saiy4BHx
Zs7dqT1q9Hdnf+lA9tyjpxKS9QJ5v2ZzQ9+04C1WY5gS
X-Google-Smtp-Source: AG47ELuX+0sWnLT5OEFcNn9x26P85sF5v7ks0xnFwjyCgbC6zLt9QUrQ5f67v94NjmpJcoDqRemUGuzhzEFQrkgRT9k=
X-Received: by 10.31.131.197 with SMTP id f188mr2781437vkd.24.1521020816699;
Wed, 14 Mar 2018 02:46:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.61.65 with HTTP; Wed, 14 Mar 2018 02:46:55 -0700 (PDT)
Received: by 10.159.61.65 with HTTP; Wed, 14 Mar 2018 02:46:55 -0700 (PDT)
In-Reply-To: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
References: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
Date: Wed, 14 Mar 2018 10:46:55 +0100
Message-ID: <CAPswA9xuVT74L87QO9TXGc6=O6Gd2kbQMBdmn=7zUm5OHXcfOA@mail.gmail.com>
To: Karl Johan Alm <karljohan-alm@garage.co.jp>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1143df5c79cc7005675c414c"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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
X-Mailman-Approved-At: Wed, 14 Mar 2018 13:10:34 +0000
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: Wed, 14 Mar 2018 09:46:58 -0000
--001a1143df5c79cc7005675c414c
Content-Type: text/plain; charset="UTF-8"
Thank you.
I can't really see from your proposal if you had thought of this: A soft
fork can make old nodes accept invalid message signatures as valid. For
example, a "signer" can use a witness version unknown to the verifier to
fool the verifier. Witness version is detectable (just reject unknown
witness versions) but there may be more subtle changes. Segwit was not
"detectable" in that way, for example.
This is the reason why I withdrew BIP120. If you have thought about the
above, I'd be very interested.
/Kalle
Sent from my Sinclair ZX81
Den 14 mars 2018 16:10 skrev "Karl Johan Alm via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
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.
RPC commands:
sign <address> <message> [<prehashed>=false]
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.
(*) Looks like you can simply use VerifyScript with a new signature
checker class. (h/t Nicolas Dorier)
(**) If <prehashed> is true, <message> is the sighash, otherwise
sighash=sha256d(message).
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--001a1143df5c79cc7005675c414c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>Thank you.=C2=A0</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">I can't really see from your proposal if you had though=
t of this: A soft fork can make old nodes accept invalid message signatures=
as valid. For example, a "signer" can use a witness version unkn=
own to the verifier to fool the verifier. Witness version is detectable (ju=
st reject unknown witness versions)=C2=A0 but there may be more subtle chan=
ges. Segwit was not "detectable" in that way, for example.=C2=A0<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">This is the reason why I=
withdrew BIP120. If you have thought about the above, I'd be very inte=
rested.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">/Kalle=C2=
=A0</div><div dir=3D"auto"><br><div data-smartmail=3D"gmail_signature" dir=
=3D"auto">Sent from my Sinclair ZX81</div><div class=3D"gmail_extra" dir=3D=
"auto"><br><div class=3D"gmail_quote">Den 14 mars 2018 16:10 skrev "Ka=
rl Johan Alm via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>>:<br type=
=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-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>
<br>
RPC commands:<br>
<br>
sign <address> <message> [<prehashed>=3Dfalse]<br>
<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>
<br>
(*) Looks like you can simply use VerifyScript with a new signature<br>
checker class. (h/t Nicolas Dorier)<br>
(**) If <prehashed> is true, <message> is the sighash, otherwis=
e<br>
sighash=3Dsha256d(message).<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div></div></div>
--001a1143df5c79cc7005675c414c--
|
