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
|
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 <roconnor@theorem.ca>) id 1RgJMB-00030Q-Pj
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Dec 2011 17:01:31 +0000
X-ACL-Warn:
Received: from erdos.theorem.ca ([72.2.4.176] helo=theorem.ca)
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1RgJM5-0001c2-RB for bitcoin-development@lists.sourceforge.net;
Thu, 29 Dec 2011 17:01:31 +0000
Received: (qmail 23357 invoked by uid 603); 29 Dec 2011 17:01:20 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 29 Dec 2011 17:01:20 -0000
Date: Thu, 29 Dec 2011 12:01:20 -0500 (EST)
From: roconnor@theorem.ca
To: Gavin Andresen <gavinandresen@gmail.com>
In-Reply-To: <CABsx9T06H29R4CpL9hXF_yyB4chko1YdkhbCZ8rdwo1gLmF1BQ@mail.gmail.com>
Message-ID: <alpine.LRH.2.00.1112291143220.22327@theorem.ca>
References: <alpine.LRH.2.00.1112290111310.22327@theorem.ca>
<CABsx9T06H29R4CpL9hXF_yyB4chko1YdkhbCZ8rdwo1gLmF1BQ@mail.gmail.com>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain -0.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RgJM5-0001c2-RB
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 17:01:31 -0000
Good morning everyone.
On Thu, 29 Dec 2011, Gavin Andresen wrote:
> 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.
Well, given the state that the OP_EVAL proposal was in when I looked at it
this week, all your code reviews you have done so far are not adequate
anyways.
Gavin, push the OP_EVAL date back 2 months. OP_EVAL just is not ready
yet.
> ... 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.
I don't understand the above paragraph.
> ----------------------
>
> 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).
This is not adequate: <data> OP_SHA256 OP_EVAL runs random code that is
more than 5 bytes.
> 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.
Yes, but maybe there is other static analysis miners may want to do. I
can't imagine every scenario.
> 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.
IMHO I think the above observation is not very relevant to the merits of
the existing OP_EVAL proposal on the table.
--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
|
