path: root/c4/02d8121bc0dcdd7d29e990ae36eeeda6f73e37

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jlrubin@mit.edu>) id 1X7ejU-00022j-Ut
	for bitcoin-development@lists.sourceforge.net;
	Thu, 17 Jul 2014 05:59:56 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of mit.edu
	designates 18.9.25.13 as permitted sender) client-ip=18.9.25.13;
	envelope-from=jlrubin@mit.edu;
	helo=dmz-mailsec-scanner-2.mit.edu; 
Received: from dmz-mailsec-scanner-2.mit.edu ([18.9.25.13])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1X7ejS-00034Z-U8
	for bitcoin-development@lists.sourceforge.net;
	Thu, 17 Jul 2014 05:59:56 +0000
X-AuditID: 1209190d-f79c06d000002f07-6f-53c766555f19
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])
	(using TLS with cipher AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP
	id AE.E4.12039.55667C35; Thu, 17 Jul 2014 01:59:49 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
	by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6H5xm16013785
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 17 Jul 2014 01:59:48 -0400
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46])
	(authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6H5xkE7007548
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 17 Jul 2014 01:59:47 -0400
Received: by mail-wg0-f46.google.com with SMTP id m15so1765227wgh.17
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 16 Jul 2014 22:59:46 -0700 (PDT)
X-Received: by 10.194.60.110 with SMTP id g14mr27327214wjr.101.1405576786141; 
	Wed, 16 Jul 2014 22:59:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.11.6 with HTTP; Wed, 16 Jul 2014 22:59:25 -0700 (PDT)
In-Reply-To: <CAJHLa0OFEDQp5umz=6_LUx5oJJmiKJoF90W7nvJPv0CtML+ftA@mail.gmail.com>
References: <CAD5xwhgyCOdJwnXw+YchptfXjtshDi_VVEGOjR-hG2qV=u6m2g@mail.gmail.com>
	<CAJHLa0OFEDQp5umz=6_LUx5oJJmiKJoF90W7nvJPv0CtML+ftA@mail.gmail.com>
From: Jeremy <jlrubin@MIT.EDU>
Date: Thu, 17 Jul 2014 01:59:25 -0400
Message-ID: <CAD5xwhhwMyL20nAUXz-Vv6m5ucH7UQcGQLyrFadAvqy4QXkbZw@mail.gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=047d7ba97be60ae8ee04fe5d599b
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrBuadjzYYFG/lEXDBF4HRo/dCz4z
	BTBGcdmkpOZklqUW6dslcGUsfveeseBoWMXuV4uYGhhPe3UxcnJICJhInP34ix3CFpO4cG89
	WxcjF4eQwGwmiV/TN7BDOA8ZJZYc3soEUiUk8JFJYtetNIjEEkaJic8/MUO0l0p8PrkYrIhX
	QFDi5MwnLBANnhIXVlwFW8EpECjxZ8UsqKnTGSU+/toFlmATkJN4cfQ82CAWAVWJpcdPsEAM
	CpBouLAbLC4sYC2xpm0JWFxEQEWi6/1RNhCbWSBO4nDXIlYI20ti9rzVbBMYhWYhuWMWktQs
	Rg4gW11i/TwhiLCaxO1tV9khbG2JZQtfMy9gZF3FKJuSW6Wbm5iZU5yarFucnJiXl1qka6SX
	m1mil5pSuokRHPSSvDsY3x1UOsQowMGoxMOb0HosWIg1say4MvcQoyQHk5Ior2bs8WAhvqT8
	lMqMxOKM+KLSnNTiQ4wSHMxKIrz1vkA53pTEyqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC
	1CKYrAwHh5IE7+EUoEbBotT01Iq0zJwShDQTByfIcB6g4a9BaniLCxJzizPTIfKnGC05mn4d
	bWPi+HXzGJD8seh0G5MQS15+XqqUOO/LZKAGAZCGjNI8uJmwJPaKURzoRWHe2yBjeYAJEG7q
	K6CFTEALy2sOgywsSURISTUwLrvKE7hVKZylPeO3fLu656EfDHWGiXmvlzcsKM4NODVnT/+a
	oNVXE3zzTFSvrCg+HsbEb55xrOdOkGff1TU+X86Vt66ZF1pkfW1C9SbpK6KfTI58v5pU3Lvs
	xaxDU1J//njkzL8+KaVZKD+hLiNog2v0Kou3r+5lGVrv/JPadkz/Q9+0qEPmSizFGYmGWsxF
	xYkANwdOtz0DAAA=
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 SPF_PASS               SPF: sender matches SPF record
	-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain 1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1X7ejS-00034Z-U8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Pay to MultiScript hash:
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: Thu, 17 Jul 2014 05:59:57 -0000

--047d7ba97be60ae8ee04fe5d599b
Content-Type: text/plain; charset=UTF-8

Additional costs would be in terms of A) chance of user error/application
error -- proposed method is much simpler, as well as extra bytes for
control flow ( 4 per script if I am counting right).


The costs on a normal script do seem slightly more friendly, except this
method allows for hidden-till-spent permission groups, as well as as
smaller blockchain bloat overall (if scriptSig script has to store the
logic for all the potential permission group, it will be a larger script
versus only needing one permission group's script). An added benefit could
also be in blockchain analysis -- you can actively monitor the utxo pool
for your known associated scripts, whereas you couldn't for specialty
scripts assembled per group. Enables repeated spends with groups as a "cost
object" w/o having to recall all participants. ie, pay to the same perm
groups as the other employee did last time, but include me as a root this
time.


Do you have a transcript of that chat by any chance? An interesting way to
do that would be to push the sigs onto the stack & have implicit orders,
then do expressions with their aliases, and then be able to assign
"spending groups".
ex:
code_sep
push script0
push script1
push script2
push script3
group_sep
mkgroup_2, 0,1      ; the id will be 4
mkgroup_3, 0,2,3   ; the id will be 5
mkUnionGroup_2, 4,5 ; the id will be 6
2_of_3_group 0, 1, 2
mkIntersectionGroup_2 5, 6
complement_last  ; complements last group, mutation
del_group 1          ; deletes the group #1, groups then reindex after
deletion (maybe the group was useful base class).
etc...
multisig check perm groups (checks if any groups on stack are valid from
script)


or even something like adding a little SAT scripting language with an eval.

push script0
push script1
push script2
push script3
push <a=(1 & 2 & 0), b=a-1, a | 3 | b >
eval











On Thu, Jul 17, 2014 at 12:52 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> On Wed, Jul 16, 2014 at 1:56 PM, Jeremy <jlrubin@mit.edu> wrote:
> > Right now, this could be expressed multiple ways (ie, using an op_dup if
> > then else chain) , but all would incur additional costs in terms of
> > complicated control flows. Instead, I would propose:
>
> Can you quantify "additional costs in terms of complicated control flows"?
>
>
> > There is an implication in terms of increased utxo pool bloat, but also
> an
> > implication in terms of increased txn complexity (each 20 byte hash
> allows
> > for a 500 byte script, only one of the 500 byte scripts has to be
> > permanently stored on blockchain).
>
> When considering these costs, using a normal P2SH output + a script
> with OP_IF and friends seems more straightforward?
>
> Doing boolean logic with multisig groups is quite possible, e.g.
> "group AND group", "group OR (group AND group)" etc.  Definitely a
> valid use case.  I discussed how to do this on IRC with gmaxwell
> several months ago.  I call it "multi-multisig" for lack of a better
> name.
>



-- 
Jeremy Rubin

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Additional costs would=
 be in terms of A) chance of user error/application error -- proposed metho=
d is much simpler, as well as extra bytes for control flow ( 4 per script i=
f I am counting right).<br>

<br><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">The costs on a normal scr=
ipt do seem slightly more friendly, except this method allows for hidden-ti=
ll-spent permission groups, as well as as smaller blockchain bloat overall =
(if scriptSig script has to store the logic for all the potential permissio=
n group, it will be a larger script=C2=A0 versus only needing one permissio=
n group&#39;s script). An added benefit could also be in blockchain analysi=
s -- you can actively monitor the utxo pool for your known associated scrip=
ts, whereas you couldn&#39;t for specialty scripts assembled per group. Ena=
bles repeated spends with groups as a &quot;cost object&quot; w/o having to=
 recall all participants. ie, pay to the same perm groups as the other empl=
oyee did last time, but include me as a root this time. <br>

<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">

Do you have a transcript of that chat by any chance? An interesting way to =
do that would be to push the sigs onto the stack &amp; have implicit orders=
, then do expressions with their aliases, and then be able to assign &quot;=
spending groups&quot;.<br>

</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)">ex:<br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)">

code_sep<br></div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)">push script0<br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">

push script1<br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">push script2<br>p=
ush script3<br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">

group_sep<br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">mkgroup_2, 0,1 =C2=
=A0=C2=A0=C2=A0=C2=A0 ; the id will be 4<br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">

mkgroup_3, 0,2,3 =C2=A0 ; the id will be 5<br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)">mkUnionGroup_2, 4,5 ; the id will be 6<br></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)">

2_of_3_group 0, 1, 2<br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">mkInterse=
ctionGroup_2 5, 6<br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">

complement_last=C2=A0 ; complements last group, mutation<br></div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)">del_group 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 ; deletes the group #1, groups then reindex after deleti=
on (maybe the group was useful base class).<br>

</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)">etc...<br></div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)">

multisig check perm groups (checks if any groups on stack are valid from sc=
ript)<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)">

<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)">or even something like adding=
 a little SAT scripting language with an eval.<br><br><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)">

push script0<br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">push script1<br><=
/div>push script2<br>push script3<br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)">

push &lt;a=3D(1 &amp; 2 &amp; 0), b=3Da-1, a | 3 | b &gt;<br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)">eval<br><br><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">

<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">

<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"><br><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)">

<br><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_=
quote">On Thu, Jul 17, 2014 at 12:52 AM, Jeff Garzik <span dir=3D"ltr">&lt;=
<a href=3D"mailto:jgarzik@bitpay.com" target=3D"_blank">jgarzik@bitpay.com<=
/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"">On Wed, Jul 16, 2014 at 1:56=
 PM, Jeremy &lt;<a href=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>&gt; =
wrote:<br>


&gt; Right now, this could be expressed multiple ways (ie, using an op_dup =
if<br>
&gt; then else chain) , but all would incur additional costs in terms of<br=
>
&gt; complicated control flows. Instead, I would propose:<br>
<br>
</div>Can you quantify &quot;additional costs in terms of complicated contr=
ol flows&quot;?<br>
<br>
<br>
&gt; There is an implication in terms of increased utxo pool bloat, but als=
o an<br>
&gt; implication in terms of increased txn complexity (each 20 byte hash al=
lows<br>
&gt; for a 500 byte script, only one of the 500 byte scripts has to be<br>
&gt; permanently stored on blockchain).<br>
<br>
When considering these costs, using a normal P2SH output + a script<br>
with OP_IF and friends seems more straightforward?<br>
<br>
Doing boolean logic with multisig groups is quite possible, e.g.<br>
&quot;group AND group&quot;, &quot;group OR (group AND group)&quot; etc. =
=C2=A0Definitely a<br>
valid use case. =C2=A0I discussed how to do this on IRC with gmaxwell<br>
several months ago. =C2=A0I call it &quot;multi-multisig&quot; for lack of =
a better<br>
name.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div dir=3D"ltr">Jeremy=
 Rubin</div>
</div>

--047d7ba97be60ae8ee04fe5d599b--