Message-ID: <1325352538.2068.YahooMailClassic@web120904.mail.ne1.yahoo.com>
Date: Sat, 31 Dec 2011 09:28:58 -0800 (PST)
From: Zell Faze <zellfaze@yahoo.com>
To: roconnor@theorem.ca, Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
In-Reply-To: <1325325253.2800.3.camel@mei>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
Precedence: list

I agree with Joel.  I think someone brought this up earlier as well.   Most=
 OP_EVAL transactions won't be complex enough to require more than a few lo=
ops.=0A=0A--Zell=0A=0A------------------------=0A"It stopped being just a w=
ebsite a long time ago. For many of us, most of us, Wikipedia has become an=
 indispensable part of our daily lives."=0A=E2=80=94 Jimmy Wales, Founder o=
f Wikipedia =0AHelp protect it now. Please make a donation today: http://ww=
w.wikimediafoundation.org/wiki/Donate=0A=0A=0A=0A--- On Sat, 12/31/11, Joel=
 Joonatan Kaartinen <joel.kaartinen@gmail.com> wrote:=0A=0A> From: Joel Joo=
natan Kaartinen <joel.kaartinen@gmail.com>=0A> Subject: Re: [Bitcoin-develo=
pment] Alternative to OP_EVAL=0A> To: roconnor@theorem.ca=0A> Cc: bitcoin-d=
evelopment@lists.sourceforge.net=0A> Date: Saturday, December 31, 2011, 4:5=
4 AM=0A> Wouldn't it work to restrict the=0A> number of executions of OP_EV=
AL allowed=0A> per transaction? That way it wouldn't allow for unlimited=0A=
> looping. If=0A> there's too many OP_EVAL executions during the transactio=
n=0A> evaluation,=0A> just consider the transaction illegal. 3 would be eno=
ugh=0A> for the=0A> purposes people have been planning for here I think.=0A=
> =0A> - Joel=0A> =0A> On Thu, 2011-12-29 at 11:42 -0500, roconnor@theorem.=
ca=0A> wrote:=0A> > On Thu, 29 Dec 2011, theymos wrote:=0A> > =0A> > > On T=
hu, Dec 29, 2011, at 01:55 AM, roconnor@theorem.ca=0A> wrote:=0A> > >> The =
number of operations executed is still=0A> bounded by the number of=0A> > >=
> operations occurring in the script.=C2=A0=0A> With the OP_EVAL proposal t=
he=0A> > >> script language becomes essentially Turing=0A> complete, with o=
nly an=0A> > >> artificial limit on recursion depth=0A> preventing arbitrar=
y computation=0A> > >> and there is no way to know what code will=0A> run w=
ithout executing it.=0A> > >=0A> > > Even if OP_EVAL allowed infinite depth=
, you'd=0A> still need to explicitly=0A> > > specify all operations perform=
ed, since there is=0A> no way of looping.=0A> > =0A> > That's not true.=C2=
=A0 Gavin himself showed how to use=0A> OP_EVAL to loop:=0A> > OP_PUSHDATA =
{OP_DUP OP_EVAL} OP_DUP OP_EVAL.=0A> > =0A> > Basically OP_DUP lets you dup=
licate the code on the=0A> stack and that is the =0A> > key to looping.=C2=
=A0 I'm pretty sure from here we get=0A> get Turing completeness. =0A> > Us=
ing the stack operations I expect you can implement=0A> the SK-calculus =0A=
> > given an OP_EVAL that allows arbitrary depth.=0A> > =0A> > OP_EVAL adds=
 dangerously expressive power to the=0A> scripting language.=0A> > =0A> =0A=
> =0A> =0A> ---------------------------------------------------------------=
---------------=0A> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you do=
n't=0A> need a complex=0A> infrastructure or vast IT resources to deliver s=
eamless,=0A> secure access to=0A> virtual desktops. With this all-in-one so=
lution, easily=0A> deploy virtual =0A> desktops for less than the cost of P=
Cs and save 60% on VDI=0A> infrastructure =0A> costs. Try it free! http://p=
.sf.net/sfu/Citrix-VDIinabox=0A> __________________________________________=
_____=0A> Bitcoin-development mailing list=0A> Bitcoin-development@lists.so=
urceforge.net=0A> https://lists.sourceforge.net/lists/listinfo/bitcoin-deve=
lopment=0A>