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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1RgIly-0001mO-Le
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Dec 2011 16:24:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=gavinandresen@gmail.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RgIlu-0000sp-TI
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Dec 2011 16:24:06 +0000
Received: by wibhq7 with SMTP id hq7so9625769wib.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 29 Dec 2011 08:23:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.181.13.179 with SMTP id ez19mr79640990wid.11.1325175836827;
Thu, 29 Dec 2011 08:23:56 -0800 (PST)
Received: by 10.223.156.77 with HTTP; Thu, 29 Dec 2011 08:23:56 -0800 (PST)
In-Reply-To: <alpine.LRH.2.00.1112290111310.22327@theorem.ca>
References: <alpine.LRH.2.00.1112290111310.22327@theorem.ca>
Date: Thu, 29 Dec 2011 11:23:56 -0500
Message-ID: <CABsx9T06H29R4CpL9hXF_yyB4chko1YdkhbCZ8rdwo1gLmF1BQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: roconnor@theorem.ca
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1RgIlu-0000sp-TI
Cc: bitcoin-development@lists.sourceforge.net, pool@deepbit.net,
webmaster@btcguild.com
Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
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: Thu, 29 Dec 2011 16:24:06 -0000
First, thanks very much to Russell for looking more closely at both
BIP 12 and the patch than anybody else-- he's found two bugs and two
things the BIP isn't clear enough on (so far).
And I've got to say, I'm very sympathetic to the "OP_EVAL starts down
the code-as-data path, and There Be Dragons" argument.
But:
I don't think the proposed alternative would be, in practice, any
better. I see two main disadvantages over OP_EVAL:
about 20-bytes larger
it means going back to where we were two months ago, writing more
code, reviewing it, finding bugs in it, backporting it so miners
running old software can support it, etc.
... and some other minor disadvantages:
'standard' scripts will need to be slightly different in the
scriptSig and the scriptPubKey
(e.g. <signature> CHECKSIG becomes <signature> CHECKSIGVERIFY
with OP_CODEHASH)
OP_EVALs are not executed, and so the code associated with them does
not have to be part of the transaction, if they are in the
non-executed branch of an OP_IF. That could be good for privacy, and
could be good for reducing block-chain size.
----------------------
In discussions in IRC yesterday, we talked a little about possible
changes to the OP_EVAL BIP to make it less subject to abuse. In
particular, the big can of worms is allowing arithmetic or bit
operations on the serialized script that will be EVAL'ed:
<serialized script> <other_data> OP_ADD OP_EVAL <-- Look! Dragons!
If <serialized script> is more than 4 bytes, that is actually illegal
right now (all of the arithmetic operations are limited to operating
on numbers that are 4 bytes of less, and I believe we could prove that
no series of operations will ever produce a value more than 5 bytes
big given the current limitations).
Which leads me to suggest that BIP 12 be amended to state that:
OP_EVAL shall cause script validation to fail if the top item on the
stack is less than 8 bytes long.
I'm tempted to propose a rule:
OP_EVAL shall fail if the top item on the stack is the result of any
calculation
... but I don't think the extra code it would take to implement that
(keep track of which items on the stack were the results of
OP_ADD/etc) is worth it.
On the "you can't tell how many CHECKSIG operations will be performed
before executing the script" issue:
That is already true, because the parameters to CHECKMULTISIG that
determine how many signatures it checks might be computed.
Finally, I would echo theymos' observation that I think we'll
eventually do something very much like OP_EVAL in the future-- maybe
to support (in a backwards-compatible way) a
quantum-computing-resistant signature algorithm or SHA3. When that is
done, I think it might make sense to do a bottom-up redesign of Script
based on what we've learned.
--
--
Gavin Andresen
|
