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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
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 "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.<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 <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>
<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--
|
