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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1V3ian-0002Jh-82
for bitcoin-development@lists.sourceforge.net;
Mon, 29 Jul 2013 08:14:09 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.111 as permitted sender)
client-ip=62.13.148.111; envelope-from=pete@petertodd.org;
helo=outmail148111.authsmtp.net;
Received: from outmail148111.authsmtp.net ([62.13.148.111])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1V3ial-00019i-DO for bitcoin-development@lists.sourceforge.net;
Mon, 29 Jul 2013 08:14:09 +0000
Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226])
by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r6T8E0bc079455; Mon, 29 Jul 2013 09:14:00 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6T8DtaN093130
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 29 Jul 2013 09:13:58 +0100 (BST)
Date: Mon, 29 Jul 2013 04:13:55 -0400
From: Peter Todd <pete@petertodd.org>
To: John Dillon <john.dillon892@googlemail.com>
Message-ID: <20130729081355.GB23180@savin>
References: <CAPaL=UV9ytoDc-0U148QSbtq=QHFAY1N=nV_1h_dRW12F6YVhA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG"
Content-Disposition: inline
In-Reply-To: <CAPaL=UV9ytoDc-0U148QSbtq=QHFAY1N=nV_1h_dRW12F6YVhA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: d20af01f-f826-11e2-98a9-0025907ec6c5
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAsUEkAYAgsB AmUbW11eUV57XGo7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqB3gJ clpPLBl7dARFeDBx YERiWj4PXkQrI0Z8
FFMCHW8AeGZhPWIC WUgJfh5UcAFPdx9C PwN5B3ZDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4sBjU7 Sx1KAjUuAUABRj4v
ZxIhMBYkRn0xZS0A
X-Authentic-SMTP: 61633532353630.1020:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -0.4 (/)
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
1.1 TRACKER_ID BODY: Incorporates a tracking ID number
X-Headers-End: 1V3ial-00019i-DO
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Opcode whitelist for P2SH?
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: Mon, 29 Jul 2013 08:14:09 -0000
--1UWUbFP1cBYEclgG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jul 28, 2013 at 07:39:08PM +0000, John Dillon wrote:
> Peter Todd recently came up with two related, and IMO very good, uses for
> non-standard transactions to implement both oracles and one-time-password
> protection of wallet funds. While the wallet fund case could be implement=
ed as
> only a single standard type, at the cost of generality, the oracle case w=
ould
> be most useful with more arbitrary rules. More generally it is also usefu=
l to
> be able to have scriptPubKeys like the following:
>=20
> n <pubkey>...<pubkey> m CHECKMULTISIG <master pubkey> CHECKSIG BOOLOR
>=20
> and many other similar constructions.
>=20
> What are your thoughts on creating a whitelist for specific opcodes that =
would
> apply to scripts serialized using P2SH, retaining the existing standard
> whitelist for scriptPubKeys? (I would still recommend dropping pay-to-pub=
key
> and pay-to-multisig due to their potential for dumping data in the UTXO s=
et)
One subtlety of what you are proposing is that we should still retain
the IsStandard() check, or to be exact the AreInputsStandard() check, if
a P2SH serialized script follows a standard form.
The reason is transaction mutability. Right now other than BIP11
CHECKMULTISIG only miners can mutate transactions because any change to
the scriptSig will render the transaction non-standard. As you know this
is a good thing because it means unconfirmed transaction chains don't
get broken in flight.
BIP11 is an interesting case because CHECKMULTISIG consumes one extra
stack item, so when you spend a BIP11 n <pubkey>...<pubkey> m
CHECKMULTISIG scriptPubKey you have to provide an additional item prior
to the signatures; usually OP_0 is used.
But we don't actually check that! You can put anything there provided it
doesn't make the scriptSig go over the standard allowed scriptSig size
of 500 bytes; for instance I (ab)used that feature just now to timestamp
my Litecoin v0.8.3.6 audit report SHA256 hash:
d0dfe270e8e8e4c0196f780d42e34d8a1121f2f8a249586aa1a2c5ebcada10b1
in transaction:
15bb08318335f94a8de154dc39b03db2cdebcc7a96ab6cec0379978676d00301
It's been suggested that we consider transactions non-standard, or just
now allowed at all in a future soft-fork, if at the end of execution
there is more than one stack item left; a opcode whitelist should
probably do this. On the other hand I've come up with some soft-fork
upgrade mechanisms that would leave extra items on the stack for
non-upgraded nodes, suggesting a soft-fork imposing this is a bad idea.
(though note how it suggests considering such tx's non-standard is
reasonable in a few ways)
CHECKMULTISIG isn't helped here because the value really is ignored - a
soft-fork to force it to always be zero might not be a bad idea, though
it's far from the only example of mutability.
I'd be interested if you can come up with an example where imposing a
one stack item at the end of execution rule causes problems.
More generally, and getting a bit off topic, I think Bitcoin should have
been designed so that CHECKSIG signed hashes of scriptPubKeys, rather
than txid:vout outputs, so that malleability wouldn't affect the
validity of a signature. Of course, this would mean that signatures
could be reused if scriptPubKeys were reused, but address re-use is a
bad thing anyway! Not that I'll fault Satoshi here, type 2 deterministic
wallets were unknown back then. (though we should be careful that a
future CHECKSIG design can go back to txid:vout references - ECC is
unique in allowing for type 2 wallets)
--=20
'peter'[:-1]@petertodd.org
0000000000000053ef658095fb45c7a86955d70c76b44264c7abce79683a8a90
--1UWUbFP1cBYEclgG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR9iRDAAoJECSBQD2l8JH7EAYH/jwWU2Ww4hfqxrrJgOxwERfS
7somJMz2xq9/fWXsLKP5u+G4FG+ANFHvfOHLnioxuMCR+Ju339MpP25BHjM8YC84
/6o7tSLKHojr/W0BMvcJSK7a3V2b8kftypKe1lrNBDrY8r4RX+toPKXnVczS3BiM
gB5MBW3arflQlbTEf/saw+eNfQwYrRj7aWVCKKM0glsFPn2NnZqO6pJWPSxluxJe
6UlRHimtxq7YG+lsz4UyNkNlTexS7hfPA24REHaJ3hJsCoSb/IbIp9b4xAsXOSWP
d8ZlMW0DHjd5BdyjzENdzBgGypThuiq6Bkx+2n+oExp+p/SHMhrqKdMJg432gRo=
=QMmk
-----END PGP SIGNATURE-----
--1UWUbFP1cBYEclgG--
|
