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
|
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 <john.dillon892@googlemail.com>) id 1V3WoG-0001Ha-Eg
for bitcoin-development@lists.sourceforge.net;
Sun, 28 Jul 2013 19:39:16 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com
designates 74.125.83.68 as permitted sender)
client-ip=74.125.83.68;
envelope-from=john.dillon892@googlemail.com;
helo=mail-ee0-f68.google.com;
Received: from mail-ee0-f68.google.com ([74.125.83.68])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V3WoE-0005uf-Kg
for bitcoin-development@lists.sourceforge.net;
Sun, 28 Jul 2013 19:39:16 +0000
Received: by mail-ee0-f68.google.com with SMTP id d41so1507229eek.3
for <bitcoin-development@lists.sourceforge.net>;
Sun, 28 Jul 2013 12:39:08 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.203.194 with SMTP id f42mr56805275eeo.53.1375040348287;
Sun, 28 Jul 2013 12:39:08 -0700 (PDT)
Received: by 10.223.12.131 with HTTP; Sun, 28 Jul 2013 12:39:08 -0700 (PDT)
Date: Sun, 28 Jul 2013 19:39:08 +0000
Message-ID: <CAPaL=UV9ytoDc-0U148QSbtq=QHFAY1N=nV_1h_dRW12F6YVhA@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(john.dillon892[at]googlemail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (john.dillon892[at]googlemail.com)
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1V3WoE-0005uf-Kg
Subject: [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: Sun, 28 Jul 2013 19:39:16 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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 implemented as
only a single standard type, at the cost of generality, the oracle case would
be most useful with more arbitrary rules. More generally it is also useful to
be able to have scriptPubKeys like the following:
n <pubkey>...<pubkey> m CHECKMULTISIG <master pubkey> CHECKSIG BOOLOR
and many other similar constructions.
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-pubkey
and pay-to-multisig due to their potential for dumping data in the UTXO set)
I'm thinking it should contain the following opcodes, picked for either being
already used, or having simple semantics:
0 to 75 byte pushdata
PUSHDATA1
1NEGATE
OP 1 to OP16 (numbers are allowed through pushdata anyway)
IF
NOTIF
ELSE
ENDIF
VERIFY
RETURN
TOALTSTACK
FROMALTSTACK (the alt-stack makes stack manipulation in complex ways possible)
DROP
DUP
SWAP
EQUAL
EQUALVERIFY
0NOTEQUAL
BOOLAND
BOOLOR
RIPEMD160
SHA1
SHA256
HASH160
HASH256
CHECKSIG
CHECKSIGVERIFY
CHECKMULTISIG
CHECKMULTISIGVERIFY
Note how this list allows for complex logic, but does not allow for arithmetic,
thus not exposing us to a source of problems in the past.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR9XMQAAoJEEWCsU4mNhiPyXoIAMz2YZsq+/YUnq5G5AEVmJL/
D7qrLpuI++auMEDoXzt8CqmXbDqci/d70IsBYeHdZkxBp2dah99iDzwIoBhtO/xh
XR8m4P+FH+IF6xbuTUAQbBQxr9VuymUatUCmsFzP0YbtPwIzJvUAqJkVeYW1DUXj
6pc9EW3iYdhAvpKNU7A19F6FA96y9m9DyBvY3TCHwzf591Ld1S8ghb9dEuKKYMGl
8TuEMMU/bytZkdD590Ww+f6ukeSOMw9C9+IpAKotB2oq4F4Vkwyzw4rd8sNRAa6c
lEDov6UtDSp4ALMfUxw/nxMO8UB43iJhu31KihcjOZpiYvRVeQlM8XLEvAafZvA=
=Jph1
-----END PGP SIGNATURE-----
|
