📅 Original date posted:2019-03-07
📝 Original message:Replies inline.
Matt
On 3/7/19 3:03 PM, Russell O'Connor wrote:
>
> * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation.
> This includes OP_CODESEPARATORs in unexecuted branches of if
> statements,
> similar to other disabled opcodes, but unlike OP_RETURN.
>
>
> OP_CODESEPARATOR is the only mechanism available that allows users to
> sign which particular branch they are authorizing for within scripts
> that have multiple possible conditions that reuse the same public key.
This is true, and yet it does not appear to actually be practically
usable. Thus far, despite a ton of effort, I have not yet seen a
practical use-case for OP_CODESEPARATOR (except for one example of it
being used to make SegWit scripts ever-so-slightly more effecient in
TumbleBit, hence why this BIP does not propose disabling it for SegWit).
> Because of P2SH you cannot know that no one is currently using this
> feature. Activating a soft-fork as describe above means these sorts of
> funds would be permanently lost. It is not acceptable to risk people's
> money like this.
(1) It has been well documented again and again that there is desire to
remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
non-segwit scripts represents a rather significant vulnerability in
Bitcoin today, and (3) lots of effort has gone into attempting to find
practical use-cases for OP_CODESEPARATOR's specific construction, with
no successes as of yet. I strongly, strongly disagree that the
highly-unlikely remote possibility that someone created something before
which could be rendered unspendable is sufficient reason to not fix a
vulnerability in Bitcoin today.
> I suggest an alternative whereby the execution of OP_CODESEPARATOR
> increases the transactions weight suitably as to temper the
> vulnerability caused by it. Alternatively there could be some sort of
> limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be
> executed per script, but that would require an argument as to why
> exceeding that limit isn't reasonable.
You could equally argue, however, that any such limit could render some
moderately-large transaction unspendable, so I'm somewhat skeptical of
this argument. Note that OP_CODESEPARATOR is non-standard, so getting
them mined is rather difficult in any case.
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 18:16:45
in reply to nevent1q…80y5
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-07 18:16:45Event JSON
{
"id": "5f4e9a8f63eab97c3c3a3b3f5d1b85ade7230fa7fe2fe555b5fd53c3d58b5fa9",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686161805,
"kind": 1,
"tags": [
[
"e",
"7188eca60b9414cacad9227d1078e0289be7e78addd56515606897419bb2cf43",
"",
"root"
],
[
"e",
"626a3ce03ca131ca80d5f2e976e27a54ef08e2252b2fe2c89d8ff21d53a6b5dd",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2019-03-07\n📝 Original message:Replies inline.\n\nMatt\n\nOn 3/7/19 3:03 PM, Russell O'Connor wrote:\n\u003e \n\u003e * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation.\n\u003e This includes OP_CODESEPARATORs in unexecuted branches of if\n\u003e statements,\n\u003e similar to other disabled opcodes, but unlike OP_RETURN.\n\u003e \n\u003e \n\u003e OP_CODESEPARATOR is the only mechanism available that allows users to \n\u003e sign which particular branch they are authorizing for within scripts \n\u003e that have multiple possible conditions that reuse the same public key.\n\nThis is true, and yet it does not appear to actually be practically \nusable. Thus far, despite a ton of effort, I have not yet seen a \npractical use-case for OP_CODESEPARATOR (except for one example of it \nbeing used to make SegWit scripts ever-so-slightly more effecient in \nTumbleBit, hence why this BIP does not propose disabling it for SegWit).\n\n\u003e Because of P2SH you cannot know that no one is currently using this \n\u003e feature. Activating a soft-fork as describe above means these sorts of \n\u003e funds would be permanently lost. It is not acceptable to risk people's \n\u003e money like this.\n\n(1) It has been well documented again and again that there is desire to \nremove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in \nnon-segwit scripts represents a rather significant vulnerability in \nBitcoin today, and (3) lots of effort has gone into attempting to find \npractical use-cases for OP_CODESEPARATOR's specific construction, with \nno successes as of yet. I strongly, strongly disagree that the \nhighly-unlikely remote possibility that someone created something before \nwhich could be rendered unspendable is sufficient reason to not fix a \nvulnerability in Bitcoin today.\n\n\u003e I suggest an alternative whereby the execution of OP_CODESEPARATOR \n\u003e increases the transactions weight suitably as to temper the \n\u003e vulnerability caused by it. Alternatively there could be some sort of \n\u003e limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be \n\u003e executed per script, but that would require an argument as to why \n\u003e exceeding that limit isn't reasonable.\n\nYou could equally argue, however, that any such limit could render some \nmoderately-large transaction unspendable, so I'm somewhat skeptical of \nthis argument. Note that OP_CODESEPARATOR is non-standard, so getting \nthem mined is rather difficult in any case.",
"sig": "e2471fba1a86a5d52c6efcadfa3817701692c77cee965d0660d8150ffc7529a2b006a0f1795b0709309af55b93c70f67701ee6ed767374248898d5ebe4f6bcdf"
}