Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of mit.edu
	designates 18.7.68.34 as permitted sender) client-ip=18.7.68.34;
	envelope-from=jlrubin@mit.edu;
	helo=dmz-mailsec-scanner-5.mit.edu; 
MIME-Version: 1.0
From: Jeremy <jlrubin@MIT.EDU>
Date: Wed, 16 Jul 2014 13:56:54 -0400
Message-ID: <CAD5xwhgyCOdJwnXw+YchptfXjtshDi_VVEGOjR-hG2qV=u6m2g@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7b8745a214449804fe53413f
Subject: [Bitcoin-development] Pay to MultiScript hash:
Precedence: list

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

Hey all,

I had an idea for a new transaction type. The base idea is that it is
matching on script hashes much like pay to script hash, but checks for one
of N scripts.

A motivating case is for "permission groups". Let's say I want to have a
single "root user" script, a 2 of 3 group, and a 2 of 2 group able to spend
a utxo. This would allow for any one of these permission groups to spend.

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:

OP_HASH160 [20-byte-hash-value 1]...[20-byte-hash-value N] OP_N
OP_MULTISCRIPTHASHVERIFY


could be spent with

...signatures... {serialized script}


=E2=80=8BAnd the alternative formulation: (more complex!)=E2=80=8B

=E2=80=8BOP_HASH160 OP_DUP [20-byte-hash-value 1]=E2=80=8B
=E2=80=8B OP_IF OP_EQUAL=E2=80=8B
=E2=80=8B OP_VERIFY OP_ELSE   <OP_DUP  [20-byte-hash-value 2]=E2=80=8B=E2=
=80=8B  OP_IF......>
OP_ENDIF=E2=80=8B



Of course, the permission group example is just one use case, there could
be other interesting combinations as well
=E2=80=8B.


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).


Looking forward to your feedback -- the idea is a bit preliminary, but I
think it could be exciting.

Best,

Jeremy




--=20
Jeremy Rubin

--047d7b8745a214449804fe53413f
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)">Hey all,<br><br></div>=
I had an idea for a new transaction type. The base idea is that it is match=
ing on script hashes much like pay to script hash, but checks for one of N =
scripts.<br>

<br>A motivating case is for &quot;permission groups&quot;. Let&#39;s say I=
 want to have a single &quot;root user&quot; script, a 2 of 3 group, and a =
2 of 2 group able to spend a utxo. This would allow for any one of these pe=
rmission groups to spend.<br>

<br>Right now, this could be expressed multiple ways (ie, using an op_dup i=
f then else chain) , but all would incur additional costs in terms of compl=
icated control flows. Instead, I would propose:<br><br>OP_HASH160 [20-byte-=
hash-value 1]...[20-byte-hash-value N] OP_N OP_MULTISCRIPTHASHVERIFY<br>

<br><br>could be spent with<br><br>...signatures... {serialized script}<br>=
<br><br><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0);display:inline">=E2=80=8BAnd the=
 alternative formulation: (more complex!)=E2=80=8B</div>

<br><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0);display:inline">=E2=80=8BOP_HASH160 =
OP_DUP [20-byte-hash-value 1]=E2=80=8B</div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0);display:inline">

=E2=80=8B OP_IF OP_EQUAL=E2=80=8B</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
;display:inline">=E2=80=8B OP_VERIFY OP_ELSE =C2=A0 &lt;OP_DUP=C2=A0 [20-by=
te-hash-value 2]=E2=80=8B=E2=80=8B=C2=A0 OP_IF......&gt; OP_ENDIF=E2=80=8B<=
/div>

<br><br><br>Of course, the permission group example is just one use case, t=
here could be other interesting combinations as well<div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0);display:inline">

=E2=80=8B.<br><br><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inli=
ne">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 all=
ows for a 500 byte script, only one of the 500 byte scripts has to be perma=
nently stored on blockchain). <br>

</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0);display:inline"><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)">

<br>Looking forward to your feedback -- the idea is a bit preliminary, but =
I think it could be exciting.<br><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)">

Best,<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>Jeremy</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)">

<br><br clear=3D"all"></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr">J=
eremy Rubin</div>
</div>

--047d7b8745a214449804fe53413f--