From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 ; Wed, 16 Jul 2014 13:57:16 -0400 Received: by mail-we0-f169.google.com with SMTP id u56so1330704wes.0 for ; 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 Date: Wed, 16 Jul 2014 13:56:54 -0400 Message-ID: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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_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
Hey all,

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

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 pe= rmission groups to spend.

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:

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 =C2=A0 <OP_DUP=C2=A0 [20-by= te-hash-value 2]=E2=80=8B=E2=80=8B=C2=A0 OP_IF......> OP_ENDIF=E2=80=8B<= /div>


Of course, the permission group example is just one use case, t= here 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 all= ows for a 500 byte script, only one of the 500 byte scripts has to be perma= nently stored on blockchain).


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

Best,

Jeremy




--
J= eremy Rubin
--047d7b8745a214449804fe53413f--