Joel Joonatan Kaartinen [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-31 🗒️ Summary of this message: Proposal to ...
📅 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.
>
🗒️ 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.
>