📅 Original date posted:2019-03-11
📝 Original message:Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size
limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few
more (overhead for varints) = 572ish bytes should be enough to completely
eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH
transactions without the need to remove it ever. I think it is worth
attempting to be a bit more clever than such a blunt rule, but it would be
much better than eliminating OP_CODESEPARATOR within P2SH entirely.
Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goal
is to eliminate the vulnerability associated with it.
On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> What about putting it in a deprecated state for some time. Adjust the
> transaction weight so using the op code is more expensive (10x, 20x?) and
> get the word out that it will be removed in the future.
>
> You could even have nodes send a reject code with the message
> “OP_CODESEPARATOR is depcrecated.”
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190311/f2053d43/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:16:51
in reply to nevent1q…z8dq
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 18:16:51Event JSON
{
"id": "1a98c9d4e464dfed1ecf9ea906cfbd1ea7b740889c0278938bad969babb93be6",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686161811,
"kind": 1,
"tags": [
[
"e",
"7188eca60b9414cacad9227d1078e0289be7e78addd56515606897419bb2cf43",
"",
"root"
],
[
"e",
"09f134752cf6bf9772603d8b00d316baaa9c73e0b7b61fad4328ecdfeaf905e2",
"",
"reply"
],
[
"p",
"352b35538b75bcd1384cb298feda615e454419aec1066329c8c3ff3ba18ee794"
]
],
"content": "📅 Original date posted:2019-03-11\n📝 Original message:Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size\nlimit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few\nmore (overhead for varints) = 572ish bytes should be enough to completely\neliminate any vulnerability caused by OP_CODESEPARATOR within P2SH\ntransactions without the need to remove it ever. I think it is worth\nattempting to be a bit more clever than such a blunt rule, but it would be\nmuch better than eliminating OP_CODESEPARATOR within P2SH entirely.\n\nRemember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goal\nis to eliminate the vulnerability associated with it.\n\nOn Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e What about putting it in a deprecated state for some time. Adjust the\n\u003e transaction weight so using the op code is more expensive (10x, 20x?) and\n\u003e get the word out that it will be removed in the future.\n\u003e\n\u003e You could even have nodes send a reject code with the message\n\u003e “OP_CODESEPARATOR is depcrecated.”\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190311/f2053d43/attachment.html\u003e",
"sig": "e86bbd287ea5d396074d32f255943d1e801175a62c9445deaa393ef06d9ebc62551105b038832d4dac905ce1ff704888a3f388559aa6619c6036b17ff29f90d6"
}