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.'' ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
