📅 Original date posted:2011-12-31
🗒️ Summary of this message: Proposal to restrict the number of executions of OP_EVAL per transaction to prevent unlimited looping and consider transactions with too many executions illegal.
📝 Original message: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.
>
Joel Joonatan Kaartinen [ARCHIVE] /
npub165…48xrx
2023-06-07 02:53:18
in reply to nevent1q…cvyu
Author Public Key
npub1654pkuj4rway0043gcu6rdh4umxescp7ew42d2czqvts3kwvg3esc48xrxPublished at
2023-06-07 02:53:18Event JSON
{
"id": "5168c83e8690ad6ceb347628346608b62fd99f4696253a543bab1de690ba797b",
"pubkey": "d52a1b72551bba47beb14639a1b6f5e6cd98603ecbaaa6ab02031708d9cc4473",
"created_at": 1686106398,
"kind": 1,
"tags": [
[
"e",
"9a940b93a02313cdd87199fd3d7a873bc06ba92e835205564dcc696f8e0046db",
"",
"root"
],
[
"e",
"ebf439e77aace9d83e7be096d13fd50a14d3f72066e55b9d72062a81d83ade13",
"",
"reply"
],
[
"p",
"ec4a4dbf50f892d8061c301520612ae1f0d68350dff4e3e14707d47419d55206"
]
],
"content": "📅 Original date posted:2011-12-31\n🗒️ Summary of this message: Proposal to restrict the number of executions of OP_EVAL per transaction to prevent unlimited looping and consider transactions with too many executions illegal.\n📝 Original message:Wouldn't it work to restrict the number of executions of OP_EVAL allowed\nper transaction? That way it wouldn't allow for unlimited looping. If\nthere's too many OP_EVAL executions during the transaction evaluation,\njust consider the transaction illegal. 3 would be enough for the\npurposes people have been planning for here I think.\n\n- Joel\n\nOn Thu, 2011-12-29 at 11:42 -0500, roconnor at theorem.ca wrote:\n\u003e On Thu, 29 Dec 2011, theymos wrote:\n\u003e \n\u003e \u003e On Thu, Dec 29, 2011, at 01:55 AM, roconnor at theorem.ca wrote:\n\u003e \u003e\u003e The number of operations executed is still bounded by the number of\n\u003e \u003e\u003e operations occurring in the script. With the OP_EVAL proposal the\n\u003e \u003e\u003e script language becomes essentially Turing complete, with only an\n\u003e \u003e\u003e artificial limit on recursion depth preventing arbitrary computation\n\u003e \u003e\u003e and there is no way to know what code will run without executing it.\n\u003e \u003e\n\u003e \u003e Even if OP_EVAL allowed infinite depth, you'd still need to explicitly\n\u003e \u003e specify all operations performed, since there is no way of looping.\n\u003e \n\u003e That's not true. Gavin himself showed how to use OP_EVAL to loop:\n\u003e OP_PUSHDATA {OP_DUP OP_EVAL} OP_DUP OP_EVAL.\n\u003e \n\u003e Basically OP_DUP lets you duplicate the code on the stack and that is the \n\u003e key to looping. I'm pretty sure from here we get get Turing completeness. \n\u003e Using the stack operations I expect you can implement the SK-calculus \n\u003e given an OP_EVAL that allows arbitrary depth.\n\u003e \n\u003e OP_EVAL adds dangerously expressive power to the scripting language.\n\u003e",
"sig": "55d8f460da0538052cb4d0ab43f12a167f2ff1de7ab5b739135300b4caebbc9cdc48047a940afc5573ea5111476bb894d63fc636b57a9b96b0e22a17f5ef7b95"
}