Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1WTuod-0005BL-7e
	for bitcoin-development@lists.sourceforge.net;
	Sat, 29 Mar 2014 15:04:59 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.41 as permitted sender)
	client-ip=209.85.219.41; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f41.google.com; 
Received: from mail-oa0-f41.google.com ([209.85.219.41])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WTuoc-0002SH-1b
	for bitcoin-development@lists.sourceforge.net;
	Sat, 29 Mar 2014 15:04:59 +0000
Received: by mail-oa0-f41.google.com with SMTP id j17so7399778oag.14
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 29 Mar 2014 08:04:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.233.201 with SMTP id ty9mr12312696obc.29.1396105492701; 
	Sat, 29 Mar 2014 08:04:52 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Sat, 29 Mar 2014 08:04:52 -0700 (PDT)
In-Reply-To: <4113697.13qtlTpVUA@crushinator>
References: <1878927.J1e3zZmtIP@crushinator> <1894130.91FUH3Vu6n@crushinator>
	<CAJHLa0NMNiX34r2AEUU9e2wRnYQ00tCpLVnQfGwN1YwdT5LHLA@mail.gmail.com>
	<4113697.13qtlTpVUA@crushinator>
Date: Sat, 29 Mar 2014 16:04:52 +0100
X-Google-Sender-Auth: aH3uBNqWqS1Xtz5itSb3oNp3uYs
Message-ID: <CANEZrP3H6sNfpwVMXMNS9C7gji-A4s0_Q5C-LaEwZ+5uKSMZ1A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: multipart/alternative; boundary=001a11c1c508f62e5604f5c0239b
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: 1WTuoc-0002SH-1b
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 15:04:59 -0000

--001a11c1c508f62e5604f5c0239b
Content-Type: text/plain; charset=UTF-8

Nobody is exactly thrilled by IsStandard, but it's not a deal-killer. If
you have a use for a new type of script it can be added, and people do
upgrade:

http://getaddr.bitnodes.io/dashboard/chart/?days=30

As you can see the 0.9 rollout is going OK. If a new script type had been
made standard for 0.9 like OP_RETURN was, I'm guessing it'll only be
another month or so and it'll be quite usable.


On Sat, Mar 29, 2014 at 3:55 PM, Matt Whitlock <bip@mattwhitlock.name>wrote:

> On Saturday, 29 March 2014, at 10:19 am, Jeff Garzik wrote:
> > On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock <bip@mattwhitlock.name>
> wrote:
> > > Multisig does not allow for the topology I described. Say the board
> has seven directors, meaning the majority threshold is four. This means the
> organization needs the consent of six individuals in order to sign a
> transaction: the president, the CFO, and any four of the board members. A
> 6-of-9 multisig would not accomplish the same policy, as then any six board
> members could successfully sign a transaction without the consent of the
> president or CFO. Of course the multi-signature scheme could be expanded to
> allow for hierarchical threshold topologies, or Shamir's Secret Sharing can
> be used to distribute keys at the second level (and further, if desired).
> >
> > Disagree with "does not allow"  Review bitcoin's script language.
> >
> > Bitcoin script can handle the use case you describe.  Add conditionals
> > to the bitcoin script, OP_IF etc.  You can do 'multisig AND multisig'
> > type boolean logic entirely in script, and be far more flexible than a
> > single CHECKMULTISIG affords.
>
> Depends on your definition of "can." Bitcoin's scripting language is
> awesome, but it's mostly useless due to the requirement that scripts match
> one of a select few "standard" templates in order to be allowed to
> propagate across the network and be mined into blocks. I really hate
> IsStandard and wish it would die.
>

--001a11c1c508f62e5604f5c0239b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Nobody is exactly thrilled by IsStandard, but it&#39;s not=
 a deal-killer. If you have a use for a new type of script it can be added,=
 and people do upgrade:<div><br></div><div><a href=3D"http://getaddr.bitnod=
es.io/dashboard/chart/?days=3D30">http://getaddr.bitnodes.io/dashboard/char=
t/?days=3D30</a><br>
</div><div><br></div><div>As you can see the 0.9 rollout is going OK. If a =
new script type had been made standard for 0.9 like OP_RETURN was, I&#39;m =
guessing it&#39;ll only be another month or so and it&#39;ll be quite usabl=
e.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat,=
 Mar 29, 2014 at 3:55 PM, Matt Whitlock <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:bip@mattwhitlock.name" target=3D"_blank">bip@mattwhitlock.name</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On S=
aturday, 29 March 2014, at 10:19 am, Jeff Garzik wrote:<br>
&gt; On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock &lt;<a href=3D"mailto:=
bip@mattwhitlock.name">bip@mattwhitlock.name</a>&gt; wrote:<br>
&gt; &gt; Multisig does not allow for the topology I described. Say the boa=
rd has seven directors, meaning the majority threshold is four. This means =
the organization needs the consent of six individuals in order to sign a tr=
ansaction: the president, the CFO, and any four of the board members. A 6-o=
f-9 multisig would not accomplish the same policy, as then any six board me=
mbers could successfully sign a transaction without the consent of the pres=
ident or CFO. Of course the multi-signature scheme could be expanded to all=
ow for hierarchical threshold topologies, or Shamir&#39;s Secret Sharing ca=
n be used to distribute keys at the second level (and further, if desired).=
<br>

&gt;<br>
&gt; Disagree with &quot;does not allow&quot; =C2=A0Review bitcoin&#39;s sc=
ript language.<br>
&gt;<br>
&gt; Bitcoin script can handle the use case you describe. =C2=A0Add conditi=
onals<br>
&gt; to the bitcoin script, OP_IF etc. =C2=A0You can do &#39;multisig AND m=
ultisig&#39;<br>
&gt; type boolean logic entirely in script, and be far more flexible than a=
<br>
&gt; single CHECKMULTISIG affords.<br>
<br>
</div></div>Depends on your definition of &quot;can.&quot; Bitcoin&#39;s sc=
ripting language is awesome, but it&#39;s mostly useless due to the require=
ment that scripts match one of a select few &quot;standard&quot; templates =
in order to be allowed to propagate across the network and be mined into bl=
ocks. I really hate IsStandard and wish it would die.<br>

</blockquote></div><br></div>

--001a11c1c508f62e5604f5c0239b--