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
|
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 38F21E92
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 20 Jul 2018 16:25:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com
[209.85.221.66])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8CED0466
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 20 Jul 2018 16:25:48 +0000 (UTC)
Received: by mail-wr1-f66.google.com with SMTP id h9-v6so11870657wro.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 20 Jul 2018 09:25:48 -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=0+sSs017hVszbmw2y0Zp4g+iDdSAPgOobuwIMFD7SW0=;
b=0qJbRPQpdVhg8mXPUhQQy0slOvTpgkMTN/85TQ//FmZhgEw1r1XZX4rsoE9wwfXiC5
HtQoKes+DSAO5KxtQtjjmxOWuOduS5fY+W33U4cGJgnTAEIkXbJw/BqMxj4afKNJnqjX
6MThcJvDKZ9yct3cyK6ghnV2fYNx8s7zSjB5WEnJf3et2GilYUWLQmZI0XEH9V9X9wFO
h8FdN/CExEdqGfzgyUvLJfAaBUtIQaQmHOaaDvVMa0fIIqaCWJbtkS3ivsyqNz+2PVUa
T9UBjc4xFxNihu+FChBpBeaC2pRdfyAbu51oaj2fVyZxsZShrm9MVG9CoOcNdhMdpSmX
E+nA==
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=0+sSs017hVszbmw2y0Zp4g+iDdSAPgOobuwIMFD7SW0=;
b=ZHpSSAkbekOdV1Giy+yRoVxbcLQ4x7lljH5yxAk3/EOXoYhmKt8jHwvksON4P3R20D
aYIFYV/lUK8eieerKx5JdEoZEZddlWR9BdoOQNPsyrpbJ5CqiGk6G+yXhVEtP0Vnf8tg
FtztKxHBLkzi3ZNnjcZCfBgG8CFmb7xYEMZmWZZTvTKNByINU85Oao+kbHczRaWXmegy
QqMh6jKHnmZvGDplT7przejPuU1HBXp4hK96dSzeSeKqqWU1AvGM8j2801W78KVLmRI4
234+tBACg4h5ISCXfqeqFW5FYfGYT4I4PPloBxDw4Q74zkn0aug6wAWsqpYo+snYuoMd
qINw==
X-Gm-Message-State: AOUpUlFVmwYonQC2IE1oBttqfapCyNoykSEHICTTeVnDTMqT7XNPFaFH
sBqmCe40oKK0DiU8EPNk+bUNbIcBzgSGLCn4ITe9Hyk=
X-Google-Smtp-Source: AAOMgpe6ODrWVXg8RGLeE22geooSv3ZYphGK5IB76nDqggJkZ0qWNb2cGvNlkRdaKX56+vc8tGrOrvX+LaCOOzlEoUk=
X-Received: by 2002:adf:9d1c:: with SMTP id
k28-v6mr2062872wre.29.1532103947064;
Fri, 20 Jul 2018 09:25:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgLrSe77sqO2iB7mYboo_HW=YjO4=AFdv7L5FUi2vygMiQ@mail.gmail.com>
<08201f2292587821e6d23f6cc201d95e6e5ad2cd.camel@timruffing.de>
<CAAS2fgSPUc7xRq36rZ9BVLjUTdd152Fgho4sjJXLhfrc71vPMw@mail.gmail.com>
<CAJowKgL-nRcruXhWdGWrT4x+oV7i3jYST2Wa3bF5m6iT_mOyMw@mail.gmail.com>
<CAPg+sBjdu4mnda-P0y7Ddu-rN7a1GiUt0hY_wYGsy_bJLKOYMA@mail.gmail.com>
<CAJowKgLSQZ1LrZayDi7EFc-NSfK_AD+zBdyaF7jBeQRP7tOwYQ@mail.gmail.com>
<CAPg+sBizrx20XShpeZRvZd4bfq1=E+MFUDmSC9X-xK1CSbV5kQ@mail.gmail.com>
<CAJowKg+=7nS4gNmtc8a4-2cu1uCOPqxjfchFwDVqUciKNMUYWQ@mail.gmail.com>
<CAJowKgJ3K=wmCEtoZXJZhrnnA8XJcHYg788KP+7MCeP4Mxf-0w@mail.gmail.com>
<CAAS2fgSmA02s6Vdk_FYv6NJ4smLBgxnuT4jRYU44G7=bbzv2MA@mail.gmail.com>
<CAJowKgJjQ8EGgbCurOSjTh8ij42_BVeD6dE0y67tzN0Zop3pyg@mail.gmail.com>
<CAAS2fgRrkzq6Fa5T_-YDwLDkwi30LpDtMObMEBE+Fmmj0LJpBw@mail.gmail.com>
<CAJowKgL0b3RT7XwRTF+ohoJCyZAW-ZJ+-8Lijj_s1rqqxgU7VQ@mail.gmail.com>
<CAJowKg+UaMsY_nL6SBfb20Ltki+LdhXOwwvG_mAsUq_ww3Tesg@mail.gmail.com>
<CALqxMTHYaspkn8JupaHBeLDxLOfZbnwcne2AVeFZe2ADOefktA@mail.gmail.com>
<CAJowKg+rC9rmv--NxtrFQ=ea4B20u0ozkmA5hARpA4wLinnVQg@mail.gmail.com>
<CAJowKg+QxcU0ECpZrvUckXQfBpn6Qri=gWzLA7+Y2mvTAq_mSw@mail.gmail.com>
<CAMZUoK=iNgsZVb89gYRDUdZu0AkTGQ8cXqqbk3NXHEONBpO5ow@mail.gmail.com>
In-Reply-To: <CAMZUoK=iNgsZVb89gYRDUdZu0AkTGQ8cXqqbk3NXHEONBpO5ow@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 20 Jul 2018 12:25:34 -0400
Message-ID: <CAJowKgJBVdJbRvf5Y6dV4o5Jf1XyELNsT+vCrp4b-86ZYr+LYQ@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>
Content-Type: multipart/alternative; boundary="0000000000008618e6057170bfaf"
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: Sun, 22 Jul 2018 12:50:59 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Multiparty signatures
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: Fri, 20 Jul 2018 16:25:49 -0000
--0000000000008618e6057170bfaf
Content-Type: text/plain; charset="UTF-8"
That's a great point. It's been solved in musig and that doesn't change
the m of n multisig construction.
You use the same musig construction where you hash all keys and sum the
multiples....and use that when computing k ... the shared blinding
factor.... you're still improving the system .... Getting a nice Shamir m
of n multisig.... with a single signature...and all the same properties
otherwise.
On Thu, Jul 19, 2018, 9:11 AM Russell O'Connor <roconnor@blockstream.io>
wrote:
> On Thu, Jul 19, 2018 at 8:16 AM, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> you can't birthday attack something where there's only a single variable
>> that you can modify.
>>
>
> When engaging in a multiparty signature, the attacker can more than one
> variable to modify. When you are party to a multi-party signature (for
> example, in some sort of coin-join protocol) it could be that every other
> participant in the multi-party signature is, in fact, the same single
> attacker representing themselves as multiple participants. This is how the
> attacker gets their hands on multiple variables.
>
>
>
--0000000000008618e6057170bfaf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">That's a great point.=C2=A0 It's been solved in m=
usig and that doesn't change the m of n multisig construction.<div dir=
=3D"auto"><br></div><div dir=3D"auto">You use the same musig construction w=
here you hash all keys and sum the multiples....and use that when computing=
k ... the shared blinding factor.... you're still improving the system=
.... Getting a nice Shamir m of n multisig.... with a single signature...a=
nd all the same properties otherwise.</div><div dir=3D"auto"><br></div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Jul 19, 2018, 9:1=
1 AM Russell O'Connor <<a href=3D"mailto:roconnor@blockstream.io">ro=
connor@blockstream.io</a>> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On=
Thu, Jul 19, 2018 at 8:16 AM, Erik Aronesty via bitcoin-dev <span dir=3D"l=
tr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">=C2=A0you c=
an't birthday attack something where there's only a single variable=
that you can modify.</div></blockquote><div><br></div><div>When engaging i=
n a multiparty signature, the attacker can more than one variable to modify=
.=C2=A0 When you are party to a multi-party signature (for example, in some=
sort of coin-join protocol) it could be that every other participant in th=
e multi-party signature is, in fact, the same single attacker representing =
themselves as multiple participants.=C2=A0 This is how the attacker gets th=
eir hands on multiple variables.<br></div><br></div><br></div></div>
</blockquote></div>
--0000000000008618e6057170bfaf--
|
