📅 Original date posted:2011-12-29
🗒️ Summary of this message: Gavin Andresen discusses the proposed OP_EVAL feature for Bitcoin and suggests amendments to make it less susceptible to abuse.
📝 Original message:Good morning everyone.
On Thu, 29 Dec 2011, Gavin Andresen wrote:
> First, thanks very much to Russell for looking more closely at both
> BIP 12 and the patch than anybody else-- he's found two bugs and two
> things the BIP isn't clear enough on (so far).
>
> And I've got to say, I'm very sympathetic to the "OP_EVAL starts down
> the code-as-data path, and There Be Dragons" argument.
>
> But:
>
> I don't think the proposed alternative would be, in practice, any
> better. I see two main disadvantages over OP_EVAL:
>
> about 20-bytes larger
>
> it means going back to where we were two months ago, writing more
> code, reviewing it, finding bugs in it, backporting it so miners
> running old software can support it, etc.
Well, given the state that the OP_EVAL proposal was in when I looked at it
this week, all your code reviews you have done so far are not adequate
anyways.
Gavin, push the OP_EVAL date back 2 months. OP_EVAL just is not ready
yet.
> ... and some other minor disadvantages:
>
> 'standard' scripts will need to be slightly different in the
> scriptSig and the scriptPubKey
> (e.g. <signature> CHECKSIG becomes <signature> CHECKSIGVERIFY
> with OP_CODEHASH)
>
> OP_EVALs are not executed, and so the code associated with them does
> not have to be part of the transaction, if they are in the
> non-executed branch of an OP_IF. That could be good for privacy, and
> could be good for reducing block-chain size.
I don't understand the above paragraph.
> ----------------------
>
> In discussions in IRC yesterday, we talked a little about possible
> changes to the OP_EVAL BIP to make it less subject to abuse. In
> particular, the big can of worms is allowing arithmetic or bit
> operations on the serialized script that will be EVAL'ed:
> <serialized script> <other_data> OP_ADD OP_EVAL <-- Look! Dragons!
>
> If <serialized script> is more than 4 bytes, that is actually illegal
> right now (all of the arithmetic operations are limited to operating
> on numbers that are 4 bytes of less, and I believe we could prove that
> no series of operations will ever produce a value more than 5 bytes
> big given the current limitations).
This is not adequate: <data> OP_SHA256 OP_EVAL runs random code that is
more than 5 bytes.
> Which leads me to suggest that BIP 12 be amended to state that:
> OP_EVAL shall cause script validation to fail if the top item on the
> stack is less than 8 bytes long.
>
> I'm tempted to propose a rule:
> OP_EVAL shall fail if the top item on the stack is the result of any
> calculation
>
> ... but I don't think the extra code it would take to implement that
> (keep track of which items on the stack were the results of
> OP_ADD/etc) is worth it.
>
> On the "you can't tell how many CHECKSIG operations will be performed
> before executing the script" issue:
>
> That is already true, because the parameters to CHECKMULTISIG that
> determine how many signatures it checks might be computed.
Yes, but maybe there is other static analysis miners may want to do. I
can't imagine every scenario.
> Finally, I would echo theymos' observation that I think we'll
> eventually do something very much like OP_EVAL in the future-- maybe
> to support (in a backwards-compatible way) a
> quantum-computing-resistant signature algorithm or SHA3. When that is
> done, I think it might make sense to do a bottom-up redesign of Script
> based on what we've learned.
IMHO I think the above observation is not very relevant to the merits of
the existing OP_EVAL proposal on the table.
--
Russell O'Connor <http://r6.ca/>;
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
roconnor at theorem.ca [ARCHIVE] /
npub1a3…zue3f
2023-06-07 02:53:28
in reply to nevent1q…du6v
Author Public Key
npub1a39ym06slzfdspsuxq2jqcf2u8cddq6sml6w8c28ql28gxw42grqlzue3fPublished at
2023-06-07 02:53:28Event JSON
{
"id": "b4c2bf6ea6b247c67ad555c5143335cf7dbba36b76a418a645f3698411e73de6",
"pubkey": "ec4a4dbf50f892d8061c301520612ae1f0d68350dff4e3e14707d47419d55206",
"created_at": 1686106408,
"kind": 1,
"tags": [
[
"e",
"9a940b93a02313cdd87199fd3d7a873bc06ba92e835205564dcc696f8e0046db",
"",
"root"
],
[
"e",
"b353e4d5861bdc3e215f9aa28db1c7450ba8be60c029d81a1925526f1457e666",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2011-12-29\n🗒️ Summary of this message: Gavin Andresen discusses the proposed OP_EVAL feature for Bitcoin and suggests amendments to make it less susceptible to abuse.\n📝 Original message:Good morning everyone.\n\nOn Thu, 29 Dec 2011, Gavin Andresen wrote:\n\n\u003e First, thanks very much to Russell for looking more closely at both\n\u003e BIP 12 and the patch than anybody else-- he's found two bugs and two\n\u003e things the BIP isn't clear enough on (so far).\n\u003e\n\u003e And I've got to say, I'm very sympathetic to the \"OP_EVAL starts down\n\u003e the code-as-data path, and There Be Dragons\" argument.\n\u003e\n\u003e But:\n\u003e\n\u003e I don't think the proposed alternative would be, in practice, any\n\u003e better. I see two main disadvantages over OP_EVAL:\n\u003e\n\u003e about 20-bytes larger\n\u003e\n\u003e it means going back to where we were two months ago, writing more\n\u003e code, reviewing it, finding bugs in it, backporting it so miners\n\u003e running old software can support it, etc.\n\nWell, given the state that the OP_EVAL proposal was in when I looked at it \nthis week, all your code reviews you have done so far are not adequate \nanyways.\n\nGavin, push the OP_EVAL date back 2 months. OP_EVAL just is not ready \nyet.\n\n\u003e ... and some other minor disadvantages:\n\u003e\n\u003e 'standard' scripts will need to be slightly different in the\n\u003e scriptSig and the scriptPubKey\n\u003e (e.g. \u003csignature\u003e CHECKSIG becomes \u003csignature\u003e CHECKSIGVERIFY\n\u003e with OP_CODEHASH)\n\u003e\n\u003e OP_EVALs are not executed, and so the code associated with them does\n\u003e not have to be part of the transaction, if they are in the\n\u003e non-executed branch of an OP_IF. That could be good for privacy, and\n\u003e could be good for reducing block-chain size.\n\nI don't understand the above paragraph.\n\n\u003e ----------------------\n\u003e\n\u003e In discussions in IRC yesterday, we talked a little about possible\n\u003e changes to the OP_EVAL BIP to make it less subject to abuse. In\n\u003e particular, the big can of worms is allowing arithmetic or bit\n\u003e operations on the serialized script that will be EVAL'ed:\n\u003e \u003cserialized script\u003e \u003cother_data\u003e OP_ADD OP_EVAL \u003c-- Look! Dragons!\n\u003e\n\u003e If \u003cserialized script\u003e is more than 4 bytes, that is actually illegal\n\u003e right now (all of the arithmetic operations are limited to operating\n\u003e on numbers that are 4 bytes of less, and I believe we could prove that\n\u003e no series of operations will ever produce a value more than 5 bytes\n\u003e big given the current limitations).\n\nThis is not adequate: \u003cdata\u003e OP_SHA256 OP_EVAL runs random code that is \nmore than 5 bytes.\n\n\u003e Which leads me to suggest that BIP 12 be amended to state that:\n\u003e OP_EVAL shall cause script validation to fail if the top item on the\n\u003e stack is less than 8 bytes long.\n\u003e\n\u003e I'm tempted to propose a rule:\n\u003e OP_EVAL shall fail if the top item on the stack is the result of any\n\u003e calculation\n\u003e\n\u003e ... but I don't think the extra code it would take to implement that\n\u003e (keep track of which items on the stack were the results of\n\u003e OP_ADD/etc) is worth it.\n\u003e\n\u003e On the \"you can't tell how many CHECKSIG operations will be performed\n\u003e before executing the script\" issue:\n\u003e\n\u003e That is already true, because the parameters to CHECKMULTISIG that\n\u003e determine how many signatures it checks might be computed.\n\nYes, but maybe there is other static analysis miners may want to do. I \ncan't imagine every scenario.\n\n\u003e Finally, I would echo theymos' observation that I think we'll\n\u003e eventually do something very much like OP_EVAL in the future-- maybe\n\u003e to support (in a backwards-compatible way) a\n\u003e quantum-computing-resistant signature algorithm or SHA3. When that is\n\u003e done, I think it might make sense to do a bottom-up redesign of Script\n\u003e based on what we've learned.\n\nIMHO I think the above observation is not very relevant to the merits of \nthe existing OP_EVAL proposal on the table.\n\n-- \nRussell O'Connor \u003chttp://r6.ca/\u003e\n``All talk about `theft,''' the general counsel of the American Graphophone\nCompany wrote, ``is the merest claptrap, for there exists no property in\nideas musical, literary or artistic, except as defined by statute.''",
"sig": "ee4fe02c5dac246124ae0d114726ea2e2d64127f77646beb1b957d8162a53b63f5b9fcac8c131485c85ce5db6d111a60db6c516adb6c99b522a9df5c1e3466f7"
}