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 ) 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 ; 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: References: Date: Thu, 29 Dec 2011 11:23:56 -0500 Message-ID: From: Gavin Andresen 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. 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. ---------------------- 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). 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