Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup

[Matt Corallo <lf-lists@mattcorallo.com>]

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.