From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 In-Reply-To: Message-ID: References: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. CHECKSIG becomes 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: > OP_ADD OP_EVAL <-- Look! Dragons! > > If 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: 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 ``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.''