From: Zell Faze <zellfaze@yahoo•com>
To: roconnor@theorem•ca, Joel Joonatan Kaartinen <joel.kaartinen@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
Date: Sat, 31 Dec 2011 09:28:58 -0800 (PST) [thread overview]
Message-ID: <1325352538.2068.YahooMailClassic@web120904.mail.ne1.yahoo.com> (raw)
In-Reply-To: <1325325253.2800.3.camel@mei>
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 loops.
--Zell
------------------------
"It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives."
— Jimmy Wales, Founder of Wikipedia
Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate
--- On Sat, 12/31/11, Joel Joonatan Kaartinen <joel.kaartinen@gmail•com> wrote:
> From: Joel Joonatan Kaartinen <joel.kaartinen@gmail•com>
> Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
> To: roconnor@theorem•ca
> Cc: bitcoin-development@lists•sourceforge.net
> Date: Saturday, December 31, 2011, 4:54 AM
> Wouldn't it work to restrict the
> number of executions of OP_EVAL allowed
> per transaction? That way it wouldn't allow for unlimited
> looping. If
> there's too many OP_EVAL executions during the transaction
> evaluation,
> just consider the transaction illegal. 3 would be enough
> for the
> purposes people have been planning for here I think.
>
> - Joel
>
> On Thu, 2011-12-29 at 11:42 -0500, roconnor@theorem•ca
> wrote:
> > On Thu, 29 Dec 2011, theymos wrote:
> >
> > > 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.
> >
> > That's not true. Gavin himself showed how to use
> OP_EVAL to loop:
> > OP_PUSHDATA {OP_DUP OP_EVAL} OP_DUP OP_EVAL.
> >
> > Basically OP_DUP lets you duplicate the code on the
> stack and that is the
> > key to looping. I'm pretty sure from here we get
> get Turing completeness.
> > Using the stack operations I expect you can implement
> the SK-calculus
> > given an OP_EVAL that allows arbitrary depth.
> >
> > OP_EVAL adds dangerously expressive power to the
> scripting language.
> >
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't
> need a complex
> infrastructure or vast IT resources to deliver seamless,
> secure access to
> virtual desktops. With this all-in-one solution, easily
> deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI
> infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
next prev parent reply other threads:[~2011-12-31 17:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-29 6:55 roconnor
2011-12-29 8:44 ` theymos
2011-12-29 16:42 ` roconnor
2011-12-30 12:01 ` Chris Double
2011-12-30 17:19 ` roconnor
2012-01-02 15:14 ` Stefan Thomas
2012-01-02 15:59 ` Gavin Andresen
2012-01-02 16:42 ` roconnor
2012-01-02 17:10 ` Stefan Thomas
2011-12-31 9:54 ` Joel Joonatan Kaartinen
2011-12-31 17:28 ` Zell Faze [this message]
2011-12-29 16:23 ` Gavin Andresen
2011-12-29 17:01 ` roconnor
2011-12-29 17:06 ` Luke-Jr
2011-12-29 18:00 ` Gavin Andresen
2011-12-29 19:54 ` Stefan Thomas
2011-12-29 19:08 ` Pieter Wuille
2011-12-29 21:00 ` Pieter Wuille
2011-12-29 21:31 ` Alan Reiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1325352538.2068.YahooMailClassic@web120904.mail.ne1.yahoo.com \
--to=zellfaze@yahoo$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=joel.kaartinen@gmail$(echo .)com \
--cc=roconnor@theorem$(echo .)ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox