summaryrefslogtreecommitdiff
path: root/26/92ad216b38bb0d89a101a30a729f28f2d83f8f
blob: 04036b3910f26d5807a9de073e09b3e76ed6dea1 (plain)
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
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 96E3AC7A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Aug 2018 12:09:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com
	[209.85.221.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7BD18619
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Aug 2018 12:09:51 +0000 (UTC)
Received: by mail-wr1-f47.google.com with SMTP id 20-v6so4573924wrb.12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Aug 2018 05:09:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=q32-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=IeMq/9YE0JSFz2BYPCUhDj0POoEkLhtVz6oVkMuO0gY=;
	b=lOALbO5g+Sy0hGGSQ/shI9Xm7+9l6VLK59oRUjs3FodSrS+NdnGM1tiswKx5vkMYAS
	T3bqUg+7p17KYLK9+N9vW5YRkyI9eJIrCKivzg84FGAaspUh18UDEVzEE4HZJGJvTj7F
	mppGgA4B5ZvU+Dzh6jCavQXg2g/J+VeFPUr7hwe+z8EYullOSAcJmnPyYbS4T45SmOIl
	tjD27jJQAa/9HSzjsOeFfUmiIrUQpxeAVtvSwmhtfjDj421F05Xgjc8p+Of/WHQsW08n
	WkxKhPnAQhLrf4Uip/+LnRAIWC3Dfk1siVCO2prGPkLclanwxuB9QzMZEr45i/HTECXc
	q/7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=IeMq/9YE0JSFz2BYPCUhDj0POoEkLhtVz6oVkMuO0gY=;
	b=bLPPv82Trf3NL3hLDFp77gXZIiH0i/Wks9aRPWQln4yo+cYeNAYAqkv+5jRbCQ4Lvl
	IP6YjdazsuotczmKL95UAEITlH9PHDTejcLEzu0GyW0JxvYvqGT8SQhp4b8G9Nr28hip
	oO/aZwWY28f1TpT4ALJy7uGfTlblB9TQfomxTOv5fig4HLtZr/7U0wTbHv6dR+Ixf1TZ
	kaTT5Kaaje3pxUWr7EdOSuOJs4X0Xyci/ea54omLVqwPN2T8g/3IgzvnhF/Y3H44Xbfr
	LR2Oue1IrQt+p5C9bhgUZcshYZxXvtPuZewXkPZlOLR+tz2wd04ENwDVvM803nNV5eLn
	VlMg==
X-Gm-Message-State: APzg51C4VYBDZIEDSt0AmKwOfyXKxuAJJ5JyiPleo6WFbCENrc72dhX2
	m5kokuMGBZcg8WjOwWq2D60SPx/jOPhuBFlCJcHjylKf2A==
X-Google-Smtp-Source: ANB0VdY6zC4uoeL2XEz50H10YTt0AncxJ1gyQ0AJjPcOxVE6wRpCzSvnZLm2pnu7E+lLsX9+/gvjs5RNOmlllaEencI=
X-Received: by 2002:adf:f687:: with SMTP id
	v7-v6mr4155789wrp.201.1535544589905; 
	Wed, 29 Aug 2018 05:09:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBj7f+=OYXuOMdNeJk3NBG67FSQSF8Xv3seFCvwxCWq69A@mail.gmail.com>
	<2e620d305c86f65cbff44b5fba548dc85c118f84.camel@timruffing.de>
	<20180812163734.GV499@boulet.lan>
In-Reply-To: <20180812163734.GV499@boulet.lan>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 29 Aug 2018 08:09:36 -0400
Message-ID: <CAJowKg+h11YkwOo-gyWCw+87Oh-9K34LOnJ1730hhpoVR2m5sA@mail.gmail.com>
To: apoelstra@wpsoftware.net, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d17720057491d5bf"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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
X-Mailman-Approved-At: Wed, 29 Aug 2018 12:30:06 +0000
Subject: Re: [bitcoin-dev] Schnorr signatures BIP
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, 29 Aug 2018 12:09:52 -0000

--000000000000d17720057491d5bf
Content-Type: text/plain; charset="UTF-8"

Note:

This spec cannot be used directly with a shamir scheme to produce
single-round threshold multisigs, because shares of point R would need to
be broadcast to share participants in order to produce valid single
signatures.

(R, s) schemes can still be used "online", if share participants publish
the R(share).... but, not sure if it matter much, this choice eliminates
offline multiparty signing in exchange for batch validation.








On Sun, Aug 12, 2018 at 12:47 PM Andrew Poelstra via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> I think it's just an oversight. We should specify that we use the standard
> encoding from section 2.3 of http://www.secg.org/sec1-v2.pdf except that
> we allow only compressed public keys.
>
> Andrew
>
>
> On Mon, Aug 06, 2018 at 11:12:48PM +0200, Tim Ruffing via bitcoin-dev
> wrote:
> > Is it intentional that the encoding of public (and private) keys is
> > unspecified? I'd consider at least the encoding of the public key to be
> > part of the signature scheme, so ideally it should be specified already
> > in this BIP. On the other hand, there may be good arguments against it,
> > but I'm not aware of any.
> >
> > This issue leads to a discrepancy between the specification and the
> > test vectors because the data fields of test vectors "are given as byte
> > arrays", including public and secret key. As a consequence, even the
> > Python reference implementation in the BIP draft doesn't work on test
> > vectors (in a strict sense).
> >
> > Best,
> > Tim
> >
> >
> > On Fri, 2018-07-06 at 11:08 -0700, Pieter Wuille via bitcoin-dev wrote:
> > > Hello everyone,
> > >
> > > Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
> > > over the same curve as is currently used in ECDSA:
> > > https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
> > >
> > > It is simply a draft specification of the signature scheme itself. It
> > > does not concern consensus rules, aggregation, or any other
> > > integration into Bitcoin - those things are left for other proposals,
> > > which can refer to this scheme if desirable. Standardizing the
> > > signature scheme is a first step towards that, and as it may be
> > > useful
> > > in other contexts to have a common Schnorr scheme available, it is
> > > its
> > > own informational BIP.
> > >
> > > If accepted, we'll work on more production-ready reference
> > > implementations and tests.
> > >
> > > This is joint work with several people listed in the document.
> > >
> > > Cheers,
> > >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>
> --
> Andrew Poelstra
> Mathematics Department, Blockstream
> Email: apoelstra at wpsoftware.net
> Web:   https://www.wpsoftware.net/andrew
>
> "A goose alone, I suppose, can know the loneliness of geese
>  who can never find their peace,
>  whether north or south or west or east"
>        --Joanna Newsom
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000d17720057491d5bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Note: <br></div><div><br></div><div>This spec cannot =
be used directly with a shamir scheme to produce single-round threshold mul=
tisigs, because shares of point R would need to be broadcast to share parti=
cipants in order to produce valid single signatures.=C2=A0=C2=A0 <br></div>=
<div><br></div><div>(R, s) schemes can still be used &quot;online&quot;, if=
 share participants publish the R(share).... but, not sure if it matter muc=
h, this choice eliminates offline multiparty signing in exchange for batch =
validation.<br></div><div><br></div><div><br></div><div><br></div><div><br>=
</div><div><br></div><div><br></div><div><br></div></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr">On Sun, Aug 12, 2018 at 12:47 PM Andrew Poels=
tra via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><br>
I think it&#39;s just an oversight. We should specify that we use the stand=
ard<br>
encoding from section 2.3 of <a href=3D"http://www.secg.org/sec1-v2.pdf" re=
l=3D"noreferrer" target=3D"_blank">http://www.secg.org/sec1-v2.pdf</a> exce=
pt that<br>
we allow only compressed public keys.<br>
<br>
Andrew<br>
<br>
<br>
On Mon, Aug 06, 2018 at 11:12:48PM +0200, Tim Ruffing via bitcoin-dev wrote=
:<br>
&gt; Is it intentional that the encoding of public (and private) keys is<br=
>
&gt; unspecified? I&#39;d consider at least the encoding of the public key =
to be<br>
&gt; part of the signature scheme, so ideally it should be specified alread=
y<br>
&gt; in this BIP. On the other hand, there may be good arguments against it=
,<br>
&gt; but I&#39;m not aware of any.<br>
&gt; <br>
&gt; This issue leads to a discrepancy between the specification and the<br=
>
&gt; test vectors because the data fields of test vectors &quot;are given a=
s byte<br>
&gt; arrays&quot;, including public and secret key. As a consequence, even =
the<br>
&gt; Python reference implementation in the BIP draft doesn&#39;t work on t=
est<br>
&gt; vectors (in a strict sense).<br>
&gt; <br>
&gt; Best,<br>
&gt; Tim<br>
&gt; <br>
&gt; <br>
&gt; On Fri, 2018-07-06 at 11:08 -0700, Pieter Wuille via bitcoin-dev wrote=
:<br>
&gt; &gt; Hello everyone,<br>
&gt; &gt; <br>
&gt; &gt; Here is a proposed BIP for 64-byte elliptic curve Schnorr signatu=
res,<br>
&gt; &gt; over the same curve as is currently used in ECDSA:<br>
&gt; &gt; <a href=3D"https://github.com/sipa/bips/blob/bip-schnorr/bip-schn=
orr.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/sipa=
/bips/blob/bip-schnorr/bip-schnorr.mediawiki</a><br>
&gt; &gt; <br>
&gt; &gt; It is simply a draft specification of the signature scheme itself=
. It<br>
&gt; &gt; does not concern consensus rules, aggregation, or any other<br>
&gt; &gt; integration into Bitcoin - those things are left for other propos=
als,<br>
&gt; &gt; which can refer to this scheme if desirable. Standardizing the<br=
>
&gt; &gt; signature scheme is a first step towards that, and as it may be<b=
r>
&gt; &gt; useful<br>
&gt; &gt; in other contexts to have a common Schnorr scheme available, it i=
s<br>
&gt; &gt; its<br>
&gt; &gt; own informational BIP.<br>
&gt; &gt; <br>
&gt; &gt; If accepted, we&#39;ll work on more production-ready reference<br=
>
&gt; &gt; implementations and tests.<br>
&gt; &gt; <br>
&gt; &gt; This is joint work with several people listed in the document.<br=
>
&gt; &gt; <br>
&gt; &gt; Cheers,<br>
&gt; &gt; <br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt; <br>
&gt; <br>
<br>
-- <br>
Andrew Poelstra<br>
Mathematics Department, Blockstream<br>
Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"noreferrer" ta=
rget=3D"_blank">wpsoftware.net</a><br>
Web:=C2=A0 =C2=A0<a href=3D"https://www.wpsoftware.net/andrew" rel=3D"noref=
errer" target=3D"_blank">https://www.wpsoftware.net/andrew</a><br>
<br>
&quot;A goose alone, I suppose, can know the loneliness of geese<br>
=C2=A0who can never find their peace,<br>
=C2=A0whether north or south or west or east&quot;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0--Joanna Newsom<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000d17720057491d5bf--