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 >