To: Russell O'Connor <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
	<CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
Date: Thu, 7 Mar 2019 19:50:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
	Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
	Consensus Cleanup
Precedence: list

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.