Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-29 📝 Original message:Right - the explanation in ...
📅 Original date posted:2014-03-29
📝 Original message: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 at 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 at 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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/2bdbbda6/attachment.html>;
📝 Original message: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 at 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 at 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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/2bdbbda6/attachment.html>;