📅 Original date posted:2011-12-31
🗒️ Summary of this message: A proposal to restrict the number of executions of OP_EVAL allowed per transaction to prevent unlimited looping. Wikipedia founder urges donations.
📝 Original message: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 at gmail.com> wrote:
> From: Joel Joonatan Kaartinen <joel.kaartinen at gmail.com>
> Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
> To: roconnor at theorem.ca
> Cc: bitcoin-development at 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 at theorem.ca
> wrote:
> > On Thu, 29 Dec 2011, theymos wrote:
> >
> > > On Thu, Dec 29, 2011, at 01:55 AM, roconnor at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Zell Faze [ARCHIVE] /
npub190…tt9rq
2023-06-07 02:53:21
in reply to nevent1q…hwz5
Author Public Key
npub19063ylrn5yfm7zdqwekeek0sa60lwku4nmvgr4jl95pkvy9dfvtqrtt9rqPublished at
2023-06-07 02:53:21Event JSON
{
"id": "0cf4ace47b82699934678e54c7fd379695abcfba9c269f4b60f3ed5bae96e4b2",
"pubkey": "2bf5127c73a113bf09a0766d9cd9f0ee9ff75b959ed881d65f2d036610ad4b16",
"created_at": 1686106401,
"kind": 1,
"tags": [
[
"e",
"9a940b93a02313cdd87199fd3d7a873bc06ba92e835205564dcc696f8e0046db",
"",
"root"
],
[
"e",
"5168c83e8690ad6ceb347628346608b62fd99f4696253a543bab1de690ba797b",
"",
"reply"
],
[
"p",
"d52a1b72551bba47beb14639a1b6f5e6cd98603ecbaaa6ab02031708d9cc4473"
]
],
"content": "📅 Original date posted:2011-12-31\n🗒️ Summary of this message: A proposal to restrict the number of executions of OP_EVAL allowed per transaction to prevent unlimited looping. Wikipedia founder urges donations.\n📝 Original message: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.\n\n--Zell\n\n------------------------\n\"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.\"\n— Jimmy Wales, Founder of Wikipedia \nHelp protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate\n\n\n\n--- On Sat, 12/31/11, Joel Joonatan Kaartinen \u003cjoel.kaartinen at gmail.com\u003e wrote:\n\n\u003e From: Joel Joonatan Kaartinen \u003cjoel.kaartinen at gmail.com\u003e\n\u003e Subject: Re: [Bitcoin-development] Alternative to OP_EVAL\n\u003e To: roconnor at theorem.ca\n\u003e Cc: bitcoin-development at lists.sourceforge.net\n\u003e Date: Saturday, December 31, 2011, 4:54 AM\n\u003e Wouldn't it work to restrict the\n\u003e number of executions of OP_EVAL allowed\n\u003e per transaction? That way it wouldn't allow for unlimited\n\u003e looping. If\n\u003e there's too many OP_EVAL executions during the transaction\n\u003e evaluation,\n\u003e just consider the transaction illegal. 3 would be enough\n\u003e for the\n\u003e purposes people have been planning for here I think.\n\u003e \n\u003e - Joel\n\u003e \n\u003e On Thu, 2011-12-29 at 11:42 -0500, roconnor at theorem.ca\n\u003e wrote:\n\u003e \u003e On Thu, 29 Dec 2011, theymos wrote:\n\u003e \u003e \n\u003e \u003e \u003e On Thu, Dec 29, 2011, at 01:55 AM, roconnor at theorem.ca\n\u003e wrote:\n\u003e \u003e \u003e\u003e The number of operations executed is still\n\u003e bounded by the number of\n\u003e \u003e \u003e\u003e operations occurring in the script. \n\u003e With the OP_EVAL proposal the\n\u003e \u003e \u003e\u003e script language becomes essentially Turing\n\u003e complete, with only an\n\u003e \u003e \u003e\u003e artificial limit on recursion depth\n\u003e preventing arbitrary computation\n\u003e \u003e \u003e\u003e and there is no way to know what code will\n\u003e run without executing it.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Even if OP_EVAL allowed infinite depth, you'd\n\u003e still need to explicitly\n\u003e \u003e \u003e specify all operations performed, since there is\n\u003e no way of looping.\n\u003e \u003e \n\u003e \u003e That's not true. Gavin himself showed how to use\n\u003e OP_EVAL to loop:\n\u003e \u003e OP_PUSHDATA {OP_DUP OP_EVAL} OP_DUP OP_EVAL.\n\u003e \u003e \n\u003e \u003e Basically OP_DUP lets you duplicate the code on the\n\u003e stack and that is the \n\u003e \u003e key to looping. I'm pretty sure from here we get\n\u003e get Turing completeness. \n\u003e \u003e Using the stack operations I expect you can implement\n\u003e the SK-calculus \n\u003e \u003e given an OP_EVAL that allows arbitrary depth.\n\u003e \u003e \n\u003e \u003e OP_EVAL adds dangerously expressive power to the\n\u003e scripting language.\n\u003e \u003e \n\u003e \n\u003e \n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't\n\u003e need a complex\n\u003e infrastructure or vast IT resources to deliver seamless,\n\u003e secure access to\n\u003e virtual desktops. With this all-in-one solution, easily\n\u003e deploy virtual \n\u003e desktops for less than the cost of PCs and save 60% on VDI\n\u003e infrastructure \n\u003e costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e",
"sig": "5abe69c76a95c4542b707143202cafb00539a156f9880ca81e918b3cebcabb4b07f0c268dd24ec183586d196bc027df80145a84ac821fb65fb755ca8be6ed417"
}