📅 Original date posted:2011-12-29
🗒️ Summary of this message: OP_EVAL proposal makes script language Turing complete with a limit on recursion depth, but all operations still need to be explicitly specified. OP_CODEHASH eliminates the need for script ops to be in strings.
📝 Original message: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.
I think that something like OP_EVAL will eventually be used to improve
Script in a backward-compatible way (enable the disabled math ops, fix
bugs, etc.), so the mechanism might as well be used now. The only
advantage I see with OP_CODEHASH is that script ops won't need to be in
Script "strings".
theymos [ARCHIVE] /
npub10v…mper0
2023-06-07 02:53:06
in reply to nevent1q…g4wj
Author Public Key
npub10vt6y7m6shn8hfuj83zjlwcga4fky38kv73qz6xlcvtj4q7fjt0sqmper0Published at
2023-06-07 02:53:06Event JSON
{
"id": "680c271c6a80a77ee670cf8da13540c1c166e5f605dd941144a36f16e6659c13",
"pubkey": "7b17a27b7a85e67ba7923c452fbb08ed536244f667a20168dfc3172a83c992df",
"created_at": 1686106386,
"kind": 1,
"tags": [
[
"e",
"9a940b93a02313cdd87199fd3d7a873bc06ba92e835205564dcc696f8e0046db",
"",
"root"
],
[
"e",
"bac72c5af06550185dcde0213900cd71e08c2bd73118f60f4433e5c9c264bf68",
"",
"reply"
],
[
"p",
"ec4a4dbf50f892d8061c301520612ae1f0d68350dff4e3e14707d47419d55206"
]
],
"content": "📅 Original date posted:2011-12-29\n🗒️ Summary of this message: OP_EVAL proposal makes script language Turing complete with a limit on recursion depth, but all operations still need to be explicitly specified. OP_CODEHASH eliminates the need for script ops to be in strings.\n📝 Original message:On Thu, Dec 29, 2011, at 01:55 AM, roconnor at theorem.ca wrote:\n\u003e The number of operations executed is still bounded by the number of\n\u003e operations occurring in the script. With the OP_EVAL proposal the\n\u003e script language becomes essentially Turing complete, with only an\n\u003e artificial limit on recursion depth preventing arbitrary computation\n\u003e and there is no way to know what code will run without executing it.\n\nEven if OP_EVAL allowed infinite depth, you'd still need to explicitly\nspecify all operations performed, since there is no way of looping.\n\nI think that something like OP_EVAL will eventually be used to improve\nScript in a backward-compatible way (enable the disabled math ops, fix\nbugs, etc.), so the mechanism might as well be used now. The only\nadvantage I see with OP_CODEHASH is that script ops won't need to be in\nScript \"strings\".",
"sig": "a89d7ea2c627a92b418f016af0795ed4c63d5adb8844faf587c25a31f77790f988405cb9dd9e1313378a8b57517396943201364e98f74d697983d6a7f015e430"
}