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
|
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 8EAED13DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Sep 2018 18:30:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 610023F7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Sep 2018 18:30:30 +0000 (UTC)
Received: by mail-wm0-f52.google.com with SMTP id f21-v6so2032459wmc.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Sep 2018 11:30:30 -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=JbX+EtC6bo+pkrh2nF0N8RsYqtuoQkBW64aLLvytchI=;
b=UVa3pZVID2uOlrW1A5UARzrjlI0gv1X4dTiE3kPbavZgUa5JOCMnjTAOd+DwePuGZP
9Fu2UyulKrE3Uja5nHW5u1ltSxn6SO3KGVCEQoAVytO0nLMq3Sl4Q5dk2f0awPj2vBcB
NG/m0x8/oUMQLHI9BsSc+5Zts4D1QnD0iGcJC7QangeFgTM1kPuTDOWB415Ey8I4IYpZ
3ysOZ8onNq0Nz2iNHyVkTPOdHRc3Gg6GAiCeGkutVwdl2XTVQoQw8QDzaCnx4pnJ+JbY
gvtTJhUC81xz8/tHwaWet3CBqpp4G/mMFD1HIU34L1UYW7UcTen0DjiD8VZ++7OZ5Rr5
YJPg==
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=JbX+EtC6bo+pkrh2nF0N8RsYqtuoQkBW64aLLvytchI=;
b=McuzxVWsX/cieaSigiK84oGd4+UV+6boEYkhRGbhMVB/iKay8UV1b50Ru8rCsjBNwK
DpmC2UGGJEPzxZhL/2hEtNqcm2C9/RjdsFch309FEzxDZ8BgKbhYzblLeOxmpOT+qP/C
AxXQrkL+AZ1KyS5WHiHKvgg6Xu8kCtVOrSXuGvdtgrftNUheUBsl/Ql99Kaiz9GZRS9M
Cs14YUrG9VjtdVqcuF2rZ76SzYn9tuRh22GTRNQT02iqngc6m0Zl2ozZzqaRM2G/r2Ak
p9qepy+7rSzJ16N+STO+HT2b+E7rPyqwqBRmQZTwd/1EHXGjZgj+hjO1S6rFdMet8Tus
hYvQ==
X-Gm-Message-State: APzg51A7ykfUxP8JF+d+kzlRoTOXMM+oK8p+zFh4MC3kPqOIG6A/n/cP
puStd36lRuXJXU3gWLxuHc17woX0oQW/e9vRyv1lZ1g=
X-Google-Smtp-Source: ANB0Vdau3mEBjQhw6JjUZoADc6TQBn51m+9rcAzS9n95vOXlVYpeYGi2inRXXuDnvM02NJOjP7FBed7+bACN9JWRxY8=
X-Received: by 2002:a1c:70b:: with SMTP id 11-v6mr2185456wmh.151.1536690628637;
Tue, 11 Sep 2018 11:30:28 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBj7f+=OYXuOMdNeJk3NBG67FSQSF8Xv3seFCvwxCWq69A@mail.gmail.com>
<2e620d305c86f65cbff44b5fba548dc85c118f84.camel@timruffing.de>
<20180812163734.GV499@boulet.lan>
<CAJowKg+h11YkwOo-gyWCw+87Oh-9K34LOnJ1730hhpoVR2m5sA@mail.gmail.com>
<20180903000518.GB18522@boulet.lan>
<CAJowKg+PDtEV3je_N9Ra6u3n4+ZQ3ozYapt8ivxGYYU28Qad+w@mail.gmail.com>
<CAAS2fgT0uBGbLBOW4TxA-qCzOLwoQ1qSV-R0dMKRzPLAm_UOqQ@mail.gmail.com>
<CAJowKg+-45h6vraL1PpnqfhHSbG+G40L+FD7xN+C-Dn1E6Y_Vg@mail.gmail.com>
<CAAS2fgSfdfQ2CiEabjrjspQGQufwzk84f1mzM1j_LRWqAPd8wA@mail.gmail.com>
<CAJowKgK3Pxev4pDH4xVLPvmHda8oAfq=fya4TY+_dodUJ7j9Nw@mail.gmail.com>
<CAAS2fgQOb4UJBkH=pMre=tsbAUmMNYx=4jkBawX4Rc_dKcpwZg@mail.gmail.com>
<CAJowKgK9UdavrGnKum43dx+DXe+LakHXuVU6bNhMFtEoy2U3Og@mail.gmail.com>
<CAAS2fgTRmsws4y7yz=584QXvjsVawY84je=jOEoXm2RK_jieXQ@mail.gmail.com>
In-Reply-To: <CAAS2fgTRmsws4y7yz=584QXvjsVawY84je=jOEoXm2RK_jieXQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 11 Sep 2018 14:30:13 -0400
Message-ID: <CAJowKgKAEY65Jxd5P6tTfn8gWCg2H2Yzi7C56=PH9Zr0AgdAPw@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="0000000000000cb8e105759cab03"
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, 12 Sep 2018 13:41:03 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Tue, 11 Sep 2018 18:30:31 -0000
--0000000000000cb8e105759cab03
Content-Type: text/plain; charset="UTF-8"
> That approach has its uses but I think that in any case where
delinearization can be used it's a better option.
I agree, communication efficiency is a concern for some applications, and I
can think of cases where delinearization is the better option as well.
For users that want an "M of N" scheme that
a) doesn't cost more to send funds
b) allows them to lose a device and keep their coins
c) allows them to establish and validate the scheme safely
... a simple, "verified signer" threshold scheme is probably the best
solution.
On Tue, Sep 11, 2018 at 1:51 PM Gregory Maxwell <greg@xiph.org> wrote:
> On Tue, Sep 11, 2018 at 5:38 PM Erik Aronesty <erik@q32.com> wrote:
> >
> > - Musig, by being M of M, is inherently prone to loss.
>
> M of M is a particular threshold. If you want M of M (there are
> plenty of cases where M of M _must_ be used) then you get the
> consequences of M of M, which presumably you want.
>
> This has nothing to do with musig. If you want a threshold other than
> M of M then you use a threshold other than M of M.
>
> No one is under the impression that M of M is somehow a replacement
> for other thresholds. We've spent more time talking about M of M in
> some writeups in the past because it's exactly the case you need for
> signature aggregation in Bitcoin and because it's a simpler case to
> explain.
>
> > - Having the senders of the G*x pubkey shares sign their messages with
> the associated private key share should be sufficient to prevent them from
> using wagner's algorithm to attack the combined key.
>
> Yes, that is one possibility which is described in the musig paper,
> but it requires users communicate an extra signature per key. So, for
> example, if used with aggregate signature it would completely
> eliminate the communications efficiency gains from aggregation, making
> aggregation worse than pointless. It also has somewhat worse failure
> properties than delinearization, because a signer that fails to
> validate other's share signatures behaves behaves exactly the same as
> a correct one, on honest inputs. That approach has its uses but I
> think that in any case where delinearization can be used it's a better
> option.
>
--0000000000000cb8e105759cab03
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>>=C2=A0 That approach has its uses but I think tha=
t in any case where delinearization can be used it's a better option.</=
div><div><br></div><div>I agree,=20
communication efficiency is a concern for some applications, and I can thin=
k of cases where=20
delinearization is the better option as well.=C2=A0=C2=A0=C2=A0 <br></div><=
div><br></div><div>For users that want an "M of N" scheme that <b=
r></div><div><br></div><div>a) doesn't cost more to send funds</div><di=
v>b) allows them to lose a device and keep their coins</div><div>c) allows =
them to establish and validate the scheme safely<br></div><div><br></div><d=
iv>...=C2=A0 a simple, "verified signer" threshold scheme is prob=
ably the best solution.</div><div><br></div><div><br></div><div class=3D"gm=
ail-adL"><br>
</div>
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Sep 11, 2018 =
at 1:51 PM Gregory Maxwell <<a href=3D"mailto:greg@xiph.org">greg@xiph.o=
rg</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Sep 11, 2=
018 at 5:38 PM Erik Aronesty <<a href=3D"mailto:erik@q32.com" target=3D"=
_blank">erik@q32.com</a>> wrote:<br>
><br>
> - Musig, by being M of M, is inherently prone to loss.<br>
<br>
M of M is a particular threshold.=C2=A0 =C2=A0If you want M of M (there are=
<br>
plenty of cases where M of M _must_ be used) then you get the<br>
consequences of M of M, which presumably you want.<br>
<br>
This has nothing to do with musig.=C2=A0 If you want a threshold other than=
<br>
M of M then you use a threshold other than M of M.<br>
<br>
No one is under the impression that M of M is somehow a replacement<br>
for other thresholds.=C2=A0 We've spent more time talking about M of M =
in<br>
some writeups in the past because it's exactly the case you need for<br=
>
signature aggregation in Bitcoin and because it's a simpler case to<br>
explain.<br>
<br>
> - Having the senders of the G*x pubkey shares sign their messages with=
the associated private key share should be sufficient to prevent them from=
using wagner's algorithm to attack the combined key.<br>
<br>
Yes, that is one possibility which is described in the musig paper,<br>
but it requires users communicate an extra signature per key.=C2=A0 So, for=
<br>
example, if used with aggregate signature it would completely<br>
eliminate the communications efficiency gains from aggregation, making<br>
aggregation worse than pointless.=C2=A0 It also has somewhat worse failure<=
br>
properties than delinearization, because a signer that fails to<br>
validate other's share signatures behaves behaves exactly the same as<b=
r>
a correct one, on honest inputs.=C2=A0 That approach has its uses but I<br>
think that in any case where delinearization can be used it's a better<=
br>
option.<br>
</blockquote></div>
--0000000000000cb8e105759cab03--
|
