From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTtQk-00054Y-PE for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 13:36:14 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.170 as permitted sender) client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f170.google.com; Received: from mail-ob0-f170.google.com ([209.85.214.170]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WTtQi-0008CS-HX for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 13:36:14 +0000 Received: by mail-ob0-f170.google.com with SMTP id uz6so7233868obc.15 for ; Sat, 29 Mar 2014 06:36:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.226.198 with SMTP id ru6mr697074oec.49.1396100167121; Sat, 29 Mar 2014 06:36:07 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Sat, 29 Mar 2014 06:36:07 -0700 (PDT) In-Reply-To: References: <1878927.J1e3zZmtIP@crushinator> <83BBF97F-290E-4CF9-B062-92445ED35F27@beams.io> <1701792.nYQmSeReja@crushinator> Date: Sat, 29 Mar 2014 14:36:07 +0100 X-Google-Sender-Auth: a2oJ_OwG-slCEuEfHv4JTZln-gQ Message-ID: From: Mike Hearn To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a11369c3e88414004f5bee635 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WTtQi-0008CS-HX 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:36:14 -0000 --001a11369c3e88414004f5bee635 Content-Type: text/plain; charset=UTF-8 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 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 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 > > > > > > -- > 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 > --001a11369c3e88414004f5bee635 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right - the explanation in the BIP about the board of =C2= =A0directors is IMO a little misleading. The problem is with splitting a pr= ivate key is that at some point, someone=C2=A0has to get the full pr= ivate 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 splittin= g a wallet seed like this, like for higher security cold wallets, but I sus= pect an ongoing shared account like a corporate account is still best off u= sing 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 mentio= n 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. =C2=A0You reconstitute a private key, which may then be used to control anything that key controls. =C2=A0Thus, 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. =C2=A0Shamir 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<= br> 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 i= nadvertent 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&#= 39;s Secret Sharing Scheme as the best tool for the job? In particular, whe= n 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 def= ense-in-depth? In any case, the Motivation and Rationale sections of the BI= P 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-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-development
>



--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/

---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11369c3e88414004f5bee635--