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
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BA6F0EA6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Apr 2016 19:03:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33820125
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Apr 2016 19:03:19 +0000 (UTC)
Received: from 058176106120.ctinets.com ([58.176.106.120]:60784 helo=2012R2)
by server47.web-hosting.com with esmtpsa
(TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1)
(envelope-from <jl2012@xbt.hk>)
id 1asES5-000tqY-LS; Mon, 18 Apr 2016 15:03:18 -0400
From: <jl2012@xbt.hk>
To: "'Tier Nolan'" <tier.nolan@gmail.com>
References: <CAE-z3OUpaMLxF9dGttzLUd6tG+nO18FMo3LZqr7taASVmrEumg@mail.gmail.com> <23e401d16552$996546d0$cc2fd470$@xbt.hk> <CAE-z3OUqEXpwGiOdv_X=T_CmtP+wwrAJALQT=Bm42K=k4mMV3Q@mail.gmail.com> <CAE8CtVkuWL7XSEi_CTbrO2Ze7Q9a+V_P6=6cqGMXMouFzCio+Q@mail.gmail.com>
<CAE-z3OWjqQ=UgNRXyxJiTzsW6Ze7Ytwz3kK2HYcC7eLy2jKnow@mail.gmail.com>
In-Reply-To: <CAE-z3OWjqQ=UgNRXyxJiTzsW6Ze7Ytwz3kK2HYcC7eLy2jKnow@mail.gmail.com>
Date: Tue, 19 Apr 2016 03:03:07 +0800
Message-ID: <00aa01d199a4$f3a41c80$daec5580$@xbt.hk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00AB_01D199E8.01C8E320"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKZ0cNygh4pHRrrw11uUfSX/C1ivAHCjXD4AwHsm+IBSSqdEgG+ZxSPncErGVA=
Content-Language: en-hk
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Authenticated-Sender: server47.web-hosting.com: jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Mon, 18 Apr 2016 19:04:25 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP CPRKV: Check private key verify
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 18 Apr 2016 19:03:19 -0000
This is a multipart message in MIME format.
------=_NextPart_000_00AB_01D199E8.01C8E320
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I just realize that if we have OP_CAT, OP_CHECKPRIVATEKEYVERIFY (aka =
OP_CHECKPRIVPUBPAIR) is not needed (and is probably better for privacy)
=20
Bob has the prikey-x for pubkey-x. Alice and Bob will agree to a random =
secret nonce, k. They calculate r, in the same way as signing a =
transaction.
=20
The script is:
=20
SIZE <r-length + 1> ADD <0x30> SWAP CAT <0x02|r-length|r> CAT SWAP CAT =
<pubkey-x> CECHKSIGVERIFY <Bob pubkey hash> CHECKSIG
=20
To redeem, Bob has to provide:
=20
<Bob sig> <0x02|s-length|s|sighashtype>
=20
With k, s and sighash, Alice (and only Alice) can recover the prikey-x =
with the well-known k-reuse exploit
( =
https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm =
)
=20
The script will be much cleaner if we remove the DER encoding in the =
next generation of CHECKSIG
=20
The benefit is prikey-x remains a secret among Alice and Bob. If they =
don=E2=80=99t mind exposing the prikey-x, they could use r =3D x =
coordinate of pubkey-x, which means k =3D prikey-x =
(https://bitcointalk.org/index.php?topic=3D291092.0) This would reduce =
the witness size a little bit as a DUP may be used
=20
From: bitcoin-dev-bounces@lists.linuxfoundation.org =
[mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] On Behalf Of Tier =
Nolan via bitcoin-dev
Sent: Monday, 29 February, 2016 19:53
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP CPRKV: Check private key verify
=20
On Mon, Feb 29, 2016 at 10:58 AM, Mats Jerratsch <matsjj@gmail.com =
<mailto:matsjj@gmail.com> > wrote:
This is actually very useful for LN too, see relevant discussion here
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/0118=
27.html
=20
Is there much demand for trying to code up a patch to the reference =
client? I did a basic one, but it would need tests etc. added.
I think that segregated witness is going to be using up any potential =
soft-fork slot for the time being anyway.
------=_NextPart_000_00AB_01D199E8.01C8E320
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 15 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-HK link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>I just =
realize that if we have OP_CAT, OP_CHECKPRIVATEKEYVERIFY (aka =
OP_CHECKPRIVPUBPAIR) is not needed (and is probably better for =
privacy)<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </=
o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>Bob has the =
prikey-x for pubkey-x. Alice and Bob will agree to a random secret =
nonce, k. They calculate r, in the same way as signing a =
transaction.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </=
o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>The script =
is:<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </=
o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>SIZE =
<r-length + 1> ADD <0x30> SWAP CAT <0x02|r-length|r> =
CAT SWAP CAT <pubkey-x> CECHKSIGVERIFY <Bob pubkey hash> =
CHECKSIG<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </=
o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>To redeem, =
Bob has to provide:<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </=
o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><Bob =
sig> <0x02|s-length|s|sighashtype><o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </=
o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>With k, s =
and sighash, Alice (and only Alice) can recover the prikey-x with the =
well-known k-reuse exploit<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>( <a =
href=3D"https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Al=
gorithm">https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_A=
lgorithm</a> )<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </=
o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>The script =
will be much cleaner if we remove the DER encoding in the next =
generation of CHECKSIG<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </=
o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>The benefit =
is prikey-x remains a secret among Alice and Bob. If they don=E2=80=99t =
mind exposing the prikey-x, they could use r =3D x coordinate of =
pubkey-x, which means k =3D prikey-x (<a =
href=3D"https://bitcointalk.org/index.php?topic=3D291092.0">https://bitco=
intalk.org/index.php?topic=3D291092.0</a>) This would reduce the witness =
size a little bit as a DUP may be used<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </=
o:p></span></p><p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span><=
/b><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'> =
bitcoin-dev-bounces@lists.linuxfoundation.org =
[mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] <b>On Behalf Of =
</b>Tier Nolan via bitcoin-dev<br><b>Sent:</b> Monday, 29 February, 2016 =
19:53<br><b>Cc:</b> Bitcoin Dev =
<bitcoin-dev@lists.linuxfoundation.org><br><b>Subject:</b> Re: =
[bitcoin-dev] BIP CPRKV: Check private key =
verify<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p> </o:p></p><div><div><div><p =
class=3DMsoNormal>On Mon, Feb 29, 2016 at 10:58 AM, Mats Jerratsch =
<<a href=3D"mailto:matsjj@gmail.com" =
target=3D"_blank">matsjj@gmail.com</a>> =
wrote:<o:p></o:p></p><blockquote style=3D'border:none;border-left:solid =
#CCCCCC 1.0pt;padding:0cm 0cm 0cm =
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5=
.0pt'><p class=3DMsoNormal>This is actually very useful for LN too, see =
relevant discussion here<br><br><a =
href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Novem=
ber/011827.html" =
target=3D"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2015-November/011827.html</a><o:p></o:p></p></blockquote><div><p =
class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'>Is there much demand for trying to code =
up a patch to the reference client? I did a basic one, but it =
would need tests etc. added.<o:p></o:p></p></div><div><p =
class=3DMsoNormal>I think that segregated witness is going to be using =
up any potential soft-fork slot for the time being =
anyway.<o:p></o:p></p></div></div></div></div></div></body></html>
------=_NextPart_000_00AB_01D199E8.01C8E320--
|
