summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeremy <jlrubin@MIT.EDU>2014-07-16 13:56:54 -0400
committerbitcoindev <bitcoindev@gnusha.org>2014-07-16 17:57:24 +0000
commitf650d39d7d6fb400bf988c4f83724281690e31f9 (patch)
treeeea143d179cbd38dfa4cdd754be07da747682c0d
parent7c265018517c03a519a4b0d0e2c040116f6d6b3e (diff)
downloadpi-bitcoindev-f650d39d7d6fb400bf988c4f83724281690e31f9.tar.gz
pi-bitcoindev-f650d39d7d6fb400bf988c4f83724281690e31f9.zip
[Bitcoin-development] Pay to MultiScript hash:
Diffstat
-rw-r--r--46/5e28e6a6ab3d5553e42b0941f0340674879222211
1 files changed, 211 insertions, 0 deletions
diff --git a/46/5e28e6a6ab3d5553e42b0941f0340674879222 b/46/5e28e6a6ab3d5553e42b0941f0340674879222
new file mode 100644
index 000000000..ae42772ae
--- /dev/null
+++ b/46/5e28e6a6ab3d5553e42b0941f0340674879222
@@ -0,0 +1,211 @@
+Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
+ helo=mx.sourceforge.net)
+ by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <jlrubin@mit.edu>) id 1X7TSG-0005mx-Fa
+ for bitcoin-development@lists.sourceforge.net;
+ Wed, 16 Jul 2014 17:57:24 +0000
+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;
+Received: from dmz-mailsec-scanner-5.mit.edu ([18.7.68.34])
+ by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
+ id 1X7TSE-0002Ra-NX for bitcoin-development@lists.sourceforge.net;
+ Wed, 16 Jul 2014 17:57:24 +0000
+X-AuditID: 12074422-f79be6d000007518-fd-53c6bcfd11c7
+Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])
+ (using TLS with cipher AES256-SHA (256/256 bits))
+ (Client did not present a certificate)
+ by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP
+ id 43.A1.29976.DFCB6C35; Wed, 16 Jul 2014 13:57:17 -0400 (EDT)
+Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
+ by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s6GHvGFq009967
+ for <bitcoin-development@lists.sourceforge.net>;
+ Wed, 16 Jul 2014 13:57:17 -0400
+Received: from mail-we0-f169.google.com (mail-we0-f169.google.com
+ [74.125.82.169]) (authenticated bits=0)
+ (User authenticated as jlrubin@ATHENA.MIT.EDU)
+ by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6GHvE4R016741
+ (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
+ for <bitcoin-development@lists.sourceforge.net>;
+ Wed, 16 Jul 2014 13:57:16 -0400
+Received: by mail-we0-f169.google.com with SMTP id u56so1330704wes.0
+ for <bitcoin-development@lists.sourceforge.net>;
+ Wed, 16 Jul 2014 10:57:14 -0700 (PDT)
+X-Received: by 10.180.21.200 with SMTP id x8mr15668658wie.67.1405533434427;
+ Wed, 16 Jul 2014 10:57:14 -0700 (PDT)
+MIME-Version: 1.0
+Received: by 10.180.11.6 with HTTP; Wed, 16 Jul 2014 10:56:54 -0700 (PDT)
+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
+X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42IRYrdT0f2751iwwcN5PBYNE3gdGD12L/jM
+ FMAYxWWTkpqTWZZapG+XwJXxbyVrwWbNig8XWhgbGO8rdzFyckgImEhsefWLDcIWk7hwbz2Q
+ zcUhJDCbSaJn0l1WkISQwENGiRkTXCASX5gkJk7uYYZwljBK7Dv7DqiFA6i9WGLBlASQBl4B
+ QYmTM5+wQDR7Smzc/RHMZhOQk3hx9DwziM0ioCqx/3ADC0R9gET3p4NMILawgKLE/C/nwGwR
+ AV2J9pb3YDXMAl4ST84/ZJ/AyD8LyYpZSFKzgK5gFlCXWD9PCCKsLbFs4WtmCFtN4va2q+zI
+ 4gsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmurlZpbopaaUbmIEh6+L0g7GnweVDjEKcDAq
+ 8fDubD8WLMSaWFZcmXuIUZKDSUmU13oXUIgvKT+lMiOxOCO+qDQntfgQowQHs5II77RZQDne
+ lMTKqtSifJiUNAeLkjjvW2urYCGB9MSS1OzU1ILUIpisDAeHkgQvMzBOhQSLUtNTK9Iyc0oQ
+ 0kwcnCDDeYCG24DU8BYXJOYWZ6ZD5E8xGnM0/TraxsTxY9HpNiYhlrz8vFQpcd7M3UClAiCl
+ GaV5cNNgKegVozjQc8K8MiADeYDpC27eK6BVTECrymsOg6wqSURISTUwTsq9uWGFZWf31WVM
+ MX+5t7pXXmdj5NxyrN/QUelZZvXaaKWitXeOG/RzHbygqvT13t79pmb7e5dYXbp/e9O8DyZH
+ HkzTdLHbv+i207yIOR1uFb8kzspGrQ+4NqkoaV9SwPaGG+0BPiFmySUPs5UtbyawtpcGlTr+
+ O1lw9dKmCl+5TPZN01dsU2Ipzkg01GIuKk4EALdMBSAcAwAA
+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: 1X7TSE-0002Ra-NX
+Subject: [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: Wed, 16 Jul 2014 17:57:24 -0000
+
+--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--
+
+
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-16 05:02:49 +0000