Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-29 🗒️ Summary of this message: OP_EVAL should ...
📅 Original date posted:2011-12-29
🗒️ Summary of this message: OP_EVAL should fail if asked to execute 8 or fewer bytes. Standard transaction types are easy to reason about, and EVAL as proposed is not a danger.
📝 Original message:RE: preventing OP_EVAL from executing the result of calculations:
> This is not adequate: <data> OP_SHA256 OP_EVAL runs random code that is more> than 5 bytes.
Good point, the rule should be "OP_EVAL shall fail if asked to execute
8 or fewer bytes."
RE: this minor disadvantage:
>> 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.
It is the "Either This or That can redeem" case that motivated me to
allow 2-deep EVAL recursion.
Start with the most straightforward code for doing "this or that" (in
pseudocode):
scriptSig: <sigs> <either the code for This or the code for That>
scriptPuKey:
IF <hash of code> EQUALS hash of This or hash of That:
EVAL
ELSE
fail validation
ENDIF
That can be done with CODESEPARATOR/CODEHASH.
But if you want to then bundle that up so the scriptPubKey is a
standard 'pay to script', you get:
scriptSig: <sigs> <either the code for This or the code for That>
<serialized IF... code from above>
scriptPubKey: ... standard DUP HASH160 <> EQUALVERIFY EVAL
To be backwards compatible with old clients the scriptSig would have to be:
<hash1> <hash2> <sigs> CODESEPARATOR this_or_that_code
CODEHASH
CODESEPARATOR
IF <hash of code> does not equal hash2:
fail verification
ENDIF
That could only be done if the definition of CODEHASH was modified to
hash only the stuff between CODESEPARATORS instead of hashing from
CODESEPARATOR to the end of the scriptSig.
RE: static analysis:
> Yes, but maybe there is other static analysis miners may want to do. I
> can't imagine every scenario.
The vast majority of miners are "discouraging" (not relaying or
putting into blocks) anything besides 'standard' transaction types.
Until somebody smarter than me (like Russell) has done a deep analysis
of Script and all of its opcodes, I don't think that should change.
The standard transaction types are easy to reason about, and the
standard types extended with OP_EVAL are also easy to reason about--
you can template-match them to find out how many ECDSA operations a
CHECKMULTISIG will do, etc.
Again, in practice, I don't think EVAL as proposed is a danger.
RE: delaying EVAL rollout: I could live with rolling out just BIP 11
(up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and
delaying EVAL rollout on the main network, but I worry that will just
encourage people to delay thoroughly reviewing/testing for a couple of
months, and we'll be right back here at the beginning of March.
--
--
Gavin Andresen
Published at
2023-06-07 02:53:35Event JSON
{
"id": "4d0b149f3f2166a99fc5576c32c51fd2201d0bd774ec365cb2dbb50652ede3e4",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686106415,
"kind": 1,
"tags": [
[
"e",
"9a940b93a02313cdd87199fd3d7a873bc06ba92e835205564dcc696f8e0046db",
"",
"root"
],
[
"e",
"8e8c9516342a0d5d42f5740b32705d46d267b20ca307450f49df6712ee3592a6",
"",
"reply"
],
[
"p",
"6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1"
]
],
"content": "📅 Original date posted:2011-12-29\n🗒️ Summary of this message: OP_EVAL should fail if asked to execute 8 or fewer bytes. Standard transaction types are easy to reason about, and EVAL as proposed is not a danger.\n📝 Original message:RE: preventing OP_EVAL from executing the result of calculations:\n\n\u003e This is not adequate: \u003cdata\u003e OP_SHA256 OP_EVAL runs random code that is more\u003e than 5 bytes.\nGood point, the rule should be \"OP_EVAL shall fail if asked to execute\n8 or fewer bytes.\"\n\nRE: this minor disadvantage:\n\n\u003e\u003e OP_EVALs are not executed, and so the code associated with them does\n\u003e\u003e not have to be part of the transaction, if they are in the\n\u003e\u003e non-executed branch of an OP_IF. That could be good for privacy, and\n\u003e\u003e could be good for reducing block-chain size.\n\n\u003e I don't understand the above paragraph.\n\nIt is the \"Either This or That can redeem\" case that motivated me to\nallow 2-deep EVAL recursion.\n\nStart with the most straightforward code for doing \"this or that\" (in\npseudocode):\n\nscriptSig: \u003csigs\u003e \u003ceither the code for This or the code for That\u003e\nscriptPuKey:\n IF \u003chash of code\u003e EQUALS hash of This or hash of That:\n EVAL\n ELSE\n fail validation\n ENDIF\n\nThat can be done with CODESEPARATOR/CODEHASH.\n\nBut if you want to then bundle that up so the scriptPubKey is a\nstandard 'pay to script', you get:\n\nscriptSig: \u003csigs\u003e \u003ceither the code for This or the code for That\u003e\n\u003cserialized IF... code from above\u003e\nscriptPubKey: ... standard DUP HASH160 \u003c\u003e EQUALVERIFY EVAL\n\nTo be backwards compatible with old clients the scriptSig would have to be:\n\n\u003chash1\u003e \u003chash2\u003e \u003csigs\u003e CODESEPARATOR this_or_that_code\n CODEHASH\n CODESEPARATOR\n IF \u003chash of code\u003e does not equal hash2:\n fail verification\n ENDIF\n\nThat could only be done if the definition of CODEHASH was modified to\nhash only the stuff between CODESEPARATORS instead of hashing from\nCODESEPARATOR to the end of the scriptSig.\n\nRE: static analysis:\n\n\u003e Yes, but maybe there is other static analysis miners may want to do. I\n\u003e can't imagine every scenario.\n\nThe vast majority of miners are \"discouraging\" (not relaying or\nputting into blocks) anything besides 'standard' transaction types.\n\nUntil somebody smarter than me (like Russell) has done a deep analysis\nof Script and all of its opcodes, I don't think that should change.\nThe standard transaction types are easy to reason about, and the\nstandard types extended with OP_EVAL are also easy to reason about--\nyou can template-match them to find out how many ECDSA operations a\nCHECKMULTISIG will do, etc.\n\nAgain, in practice, I don't think EVAL as proposed is a danger.\n\nRE: delaying EVAL rollout: I could live with rolling out just BIP 11\n(up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and\ndelaying EVAL rollout on the main network, but I worry that will just\nencourage people to delay thoroughly reviewing/testing for a couple of\nmonths, and we'll be right back here at the beginning of March.\n\n-- \n--\nGavin Andresen",
"sig": "c416a10da457a87f94c66e380e21fca288c3491fee8cd65a6ed66669331eece2f417bb77c2689479e8df204fd4be8cb03a0d887a0681554dbc306d83e8b33b61"
}