Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-07 📝 Original message:Replies inline. Matt On ...
📅 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.
📝 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.