From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RgLLN-00080s-4M for bitcoin-development@lists.sourceforge.net; Thu, 29 Dec 2011 19:08:49 +0000 X-ACL-Warn: Received: from rhcavuit02.kulnet.kuleuven.be ([134.58.240.130] helo=cavuit02.kulnet.kuleuven.be) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1RgLLL-0006Fq-Ho for bitcoin-development@lists.sourceforge.net; Thu, 29 Dec 2011 19:08:49 +0000 X-KULeuven-Envelope-From: sipa@ulyssis.org X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5, autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00, FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20) X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: E71A512808B.A7F91 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be [134.58.240.74]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id E71A512808B for ; Thu, 29 Dec 2011 20:08:39 +0100 (CET) Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be [193.190.253.235]) by smtps01.kuleuven.be (Postfix) with ESMTP id B38C931E702 for ; Thu, 29 Dec 2011 20:08:39 +0100 (CET) Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182]) by smtp.ulyssis.org (Postfix) with ESMTP id D837210052 for ; Thu, 29 Dec 2011 20:08:39 +0100 (CET) Received: by wop.ulyssis.org (Postfix, from userid 615) id D0A6D87C1AB; Thu, 29 Dec 2011 20:08:39 +0100 (CET) Date: Thu, 29 Dec 2011 20:08:39 +0100 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Pieter Wuille To: bitcoin-development@lists.sourceforge.net Message-ID: <20111229190838.GA29609@ulyssis.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1RgLLL-0006Fq-Ho 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 19:08:49 -0000 On Thu, Dec 29, 2011 at 01:55:03AM -0500, roconnor@theorem.ca wrote: > Gavin asked me to come up with an alternative to OP_EVAL, so here is my > proposal. > > OP_CODEHASH Initial Proposal If we're again brainstorming about alternatives for OP_EVAL, I'll do my own. It is called OP_CHECKEDEVAL, and is specified as follows: * It looks at the two elements most recently (in code position) pushed by a literal, and not yet consumed by another OP_CHECKEDEVAL. These are S (the serialized script), and H (its hash). This implies it defines its own literal-only stack, where all literals push to, and only OP_CHECKEDEVAL pops from. This special stack has the advantage of allowing static analysis - one does not need to execute any operations to find out which data will end up on it. Note that "skipped" code (inside the ignored part of an IF-THEN-ELSE) can still push to the literal stack. * For the "outer script", it does not have any effect at all, except for: * 2 elements popped from the literal-only stack * potentially causing failure It does not touch the main stack, alt stack or any other part of the execution state not listed above. * Failure is caused when either of these conditions hold: * No two elements remain on the literal-only stack * The Hash(S) != H * The inner script execution caused failure * For the execution of the inner script: * It is executed in a completely new and independent execution environnement * It executes the deserialized S * It inherits the main stack and alt stack (without the serialized script and the hash themselves) from the outer execution. This requires OP_CHECKEDEVAL to immediately follow the push of script and hash, so the code in the pair <