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 ) 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 In-Reply-To: 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> To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 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 = 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

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.

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.


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.

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."

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.

(None of this implies making an informational BIP lacks value; I'm all
for an informational BIP)




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
>



--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--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--