summaryrefslogtreecommitdiff
path: root/7f/eea8f4bd52deed9ddab53ae07bc3cf3bea7979
blob: 7bda81e9124c0124d4d5b8e57f40cc838be08bda (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
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--