Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of mm.st
	designates 66.111.4.26 as permitted sender)
	client-ip=66.111.4.26; envelope-from=theymos@mm.st;
	helo=out2.smtp.messagingengine.com; 
Message-Id: <1325148259.14431.140661016987461@webmail.messagingengine.com>
From: "theymos" <theymos@mm.st>
To: bitcoin-development@lists.sourceforge.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <alpine.LRH.2.00.1112290111310.22327@theorem.ca>
References: <alpine.LRH.2.00.1112290111310.22327@theorem.ca>
Date: Thu, 29 Dec 2011 02:44:19 -0600
Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
Precedence: list

On Thu, Dec 29, 2011, at 01:55 AM, roconnor@theorem.ca wrote:
> The number of operations executed is still bounded by the number of
> operations occurring in the script.  With the OP_EVAL proposal the
> script language becomes essentially Turing complete, with only an
> artificial limit on recursion depth preventing arbitrary computation
> and there is no way to know what code will run without executing it.

Even if OP_EVAL allowed infinite depth, you'd still need to explicitly
specify all operations performed, since there is no way of looping.

I think that something like OP_EVAL will eventually be used to improve
Script in a backward-compatible way (enable the disabled math ops, fix
bugs, etc.), so the mechanism might as well be used now. The only
advantage I see with OP_CODEHASH is that script ops won't need to be in
Script "strings".