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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tamas@bitsofproof.com>) id 1WTtTU-0005Be-Vc
for bitcoin-development@lists.sourceforge.net;
Sat, 29 Mar 2014 13:39:04 +0000
X-ACL-Warn:
Received: from wp059.webpack.hosteurope.de ([80.237.132.66])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WTtTR-0007tp-6Y
for bitcoin-development@lists.sourceforge.net;
Sat, 29 Mar 2014 13:39:04 +0000
Received: from [37.143.74.116] (helo=[192.168.2.2]); authenticated
by wp059.webpack.hosteurope.de running ExIM with esmtpsa
(TLS1.0:RSA_AES_128_CBC_SHA1:16)
id 1WTtTK-0004lJ-86; Sat, 29 Mar 2014 14:38:54 +0100
Content-Type: multipart/signed;
boundary="Apple-Mail=_67D360FA-7AE8-4100-A0A7-29F27E197950";
protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Tamas Blummer <tamas@bitsofproof.com>
In-Reply-To: <CANEZrP0WAMGV_ki3+9eFPaLQQVS7BJQ1c1c7KDuQatTeun-VwA@mail.gmail.com>
Date: Sat, 29 Mar 2014 14:38:53 +0100
Message-Id: <7AB025F4-3C78-4E8E-B57D-2D5348CF95B1@bitsofproof.com>
References: <1878927.J1e3zZmtIP@crushinator>
<83BBF97F-290E-4CF9-B062-92445ED35F27@beams.io>
<1701792.nYQmSeReja@crushinator>
<CA0DE0F6-C5B9-4BC4-9F79-D98C89A159F4@beams.io>
<CAJHLa0N0YCHfBeDq+QLqK3ZVWD-rAx85MXvX4OBqSoQqgCXm2w@mail.gmail.com>
<CANEZrP0WAMGV_ki3+9eFPaLQQVS7BJQ1c1c7KDuQatTeun-VwA@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
X-Mailer: Apple Mail (2.1510)
X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1396100341;
02908efc;
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1WTtTR-0007tp-6Y
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret
Sharing of Bitcoin private keys
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 29 Mar 2014 13:39:05 -0000
--Apple-Mail=_67D360FA-7AE8-4100-A0A7-29F27E197950
Content-Type: multipart/alternative;
boundary="Apple-Mail=_E516A7BD-B408-48E2-A17B-192A95BB11E5"
--Apple-Mail=_E516A7BD-B408-48E2-A17B-192A95BB11E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
This is why my motivation is rather secure backup, not multisig. Instead =
of storing encrypted seed in one location and the passphrase for it in =
an other location, one can just store two shares in two places.
> Right - the explanation in the BIP about the board of directors is =
IMO a little misleading. The problem is with splitting a private key is =
that at some point, someone has to get the full private key back and =
they can then just remember the private key to undo the system. =
CHECKMULTISIG avoids this.
>=20
> I can imagine that there may be occasional uses for splitting a wallet =
seed like this, like for higher security cold wallets, but I suspect an =
ongoing shared account like a corporate account is still best off using =
CHECKMULTISIG or the n-of-m ECDSA threshold scheme proposed by Ali et =
al.
>=20
>=20
> On Sat, Mar 29, 2014 at 2:27 PM, Jeff Garzik <jgarzik@bitpay.com> =
wrote:
> The comparison with multisig fails to mention that multi-signature
> transactions explicitly define security at the transaction level.
> This permits fine-grained specificity of what a key holder may
> approve.
>=20
> Shamir is much more coarse-grained. You reconstitute a private key,
> which may then be used to control anything that key controls. Thus,
> in addition to Shamir itself, you need policies such as "no key
> reuse."
>=20
> My first impression of Shamir many moons ago was "cool!" but that's
> since been tempered by thinking through the use cases. Shamir has a
> higher D.I.Y. factor, with a correspondingly larger surface of
> things-that-could-go-wrong, IMO.
>=20
> (None of this implies making an informational BIP lacks value; I'm all
> for an informational BIP)
>=20
>=20
>=20
>=20
> On Sat, Mar 29, 2014 at 7:54 AM, Chris Beams <chris@beams.io> wrote:
> > Enlightening; thanks, Matt. And apologies to the list for my earlier =
inadvertent double-post.
> >
> > On Mar 29, 2014, at 12:16 PM, Matt Whitlock <bip@mattwhitlock.name> =
wrote:
> >
> >> On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote:
> >>> Matt, could you expand on use cases for which you see Shamir's =
Secret Sharing Scheme as the best tool for the job? In particular, when =
do you see that it would be superior to simply going with multisig in =
the first place? Perhaps you see these as complimentary approaches, =
toward defense-in-depth? In any case, the Motivation and Rationale =
sections of the BIP in its current form are silent on these questions.
> >>
> >> I have added two new sections to address your questions.
> >>
> >> https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
> >
> >
> > =
--------------------------------------------------------------------------=
----
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>=20
>=20
>=20
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>=20
> =
--------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
> =
--------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--Apple-Mail=_E516A7BD-B408-48E2-A17B-192A95BB11E5
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>This is why my motivation is rather secure backup, not multisig. Instead of storing encrypted seed in one location and the passphrase for it in an other location, one can just store two shares in two places.<br><div><br></div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Right - the explanation in the BIP about the board of directors is IMO a little misleading. The problem is with splitting a private key is that at some point, <i>someone</i> has to get the full private key back and they can then just remember the private key to undo the system. CHECKMULTISIG avoids this.<div>
<br></div><div>I can imagine that there may be occasional uses for splitting a wallet seed like this, like for higher security cold wallets, but I suspect an ongoing shared account like a corporate account is still best off using CHECKMULTISIG or the n-of-m ECDSA threshold scheme proposed by Ali et al.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 29, 2014 at 2:27 PM, Jeff Garzik <span dir="ltr"><<a href="mailto:jgarzik@bitpay.com" target="_blank">jgarzik@bitpay.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The comparison with multisig fails to mention that multi-signature<br>
transactions explicitly define security at the transaction level.<br>
This permits fine-grained specificity of what a key holder may<br>
approve.<br>
<br>
Shamir is much more coarse-grained. You reconstitute a private key,<br>
which may then be used to control anything that key controls. Thus,<br>
in addition to Shamir itself, you need policies such as "no key<br>
reuse."<br>
<br>
My first impression of Shamir many moons ago was "cool!" but that's<br>
since been tempered by thinking through the use cases. Shamir has a<br>
higher D.I.Y. factor, with a correspondingly larger surface of<br>
things-that-could-go-wrong, IMO.<br>
<br>
(None of this implies making an informational BIP lacks value; I'm all<br>
for an informational BIP)<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On Sat, Mar 29, 2014 at 7:54 AM, Chris Beams <<a href="mailto:chris@beams.io">chris@beams.io</a>> wrote:<br>
> Enlightening; thanks, Matt. And apologies to the list for my earlier inadvertent double-post.<br>
><br>
> On Mar 29, 2014, at 12:16 PM, Matt Whitlock <<a href="mailto:bip@mattwhitlock.name">bip@mattwhitlock.name</a>> wrote:<br>
><br>
>> On Saturday, 29 March 2014, at 10:08 am, Chris Beams wrote:<br>
>>> Matt, could you expand on use cases for which you see Shamir's Secret Sharing Scheme as the best tool for the job? In particular, when do you see that it would be superior to simply going with multisig in the first place? Perhaps you see these as complimentary approaches, toward defense-in-depth? In any case, the Motivation and Rationale sections of the BIP in its current form are silent on these questions.<br>
>><br>
>> I have added two new sections to address your questions.<br>
>><br>
>> <a href="https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki" target="_blank">https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki</a><br>
><br>
><br>
</div></div><div class="im HOEnZb">> ------------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
><br>
<br>
<br>
<br>
</div><span class="HOEnZb"><font color="#888888">--<br>
Jeff Garzik<br>
Bitcoin core developer and open source evangelist<br>
BitPay, Inc. <a href="https://bitpay.com/" target="_blank">https://bitpay.com/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
------------------------------------------------------------------------------<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div></div></blockquote></div><br></div>
------------------------------------------------------------------------------<br>_______________________________________________<br>Bitcoin-development mailing list<br><a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>https://lists.sourceforge.net/lists/listinfo/bitcoin-development<br></blockquote></div><br></body></html>
--Apple-Mail=_E516A7BD-B408-48E2-A17B-192A95BB11E5--
--Apple-Mail=_67D360FA-7AE8-4100-A0A7-29F27E197950
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJTNsztAAoJEPZykcUXcTkczMkIALtpCT/oIJPnL9QQbIUbC1zv
8LtsJYM3S0O+jv65dZ9T78CrTTShAT9UZgb7kEfPBN+PV3S7smHvpcdBUE0DQaPj
Pzzwpzfw25VQQbEEIgvPnpIoIxe9CopeKBCahud1yRJyx2YO6AI+L2Bpun7CMzJ4
rNk6RkKuqfbKYCvIKgVkFGkXgiZcgN/XoAgD3DL+/zg+SMQZu7sLFgF2t49nHLeW
7DVtxkyiIUgTnvMwASXtA4PMz1x/3zipF8GOUOZa94X9E5fgxA0NYomvGHfMZToK
xaa/7gNPCiM8i+la4KjtfI+6tY8W+Oh0/lMnh3ERWePVMKf9JoUb4lt4YEuvK8I=
=hscI
-----END PGP SIGNATURE-----
--Apple-Mail=_67D360FA-7AE8-4100-A0A7-29F27E197950--
|
