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

From: Matt Corallo <lf-lists@mattcorallo•com>
To: Russell O'Connor <roconnor@blockstream•io>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
Date: Mon, 11 Mar 2019 22:23:33 -0400	[thread overview]
Message-ID: <FD3AE549-3DD4-48E0-9804-73BFBB30A9B0@mattcorallo.com> (raw)
In-Reply-To: <CAMZUoKkJY6UpN=OmOsR0tDAwLw++dYrZtuo_Vir-+DHrK3ckNg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]

I think you may have misunderstood part of the motivation. Yes, part of the motivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the theoretical operation of checksig operations (thus somewhat simplifying the implementation but also simplifying analysis of future changes, such as sighash-caching code).

I think a key part of the analysis here is that no one I've spoken to (and we've been discussing removing it for *years*, including many attempts at coming up with reasons to keep it) is aware of any real proposals to use OP_CODESEPARATOR, let alone anyone using it in the wild. Hiding data in invalid pubic keys is a long-discussed-and-implemented idea (despite it's discouragement, not to mention it appears on the chain in many places).

It would end up being a huge shame to have all the OP_CORESEPARATOR mess left around after all the effort that has gone into removing it for the past few years, especially given the stark difference in visibility of a fork when compared to a standardness change.

As for your specific proposal of increasing the weight of anything that has an OP_CODESEPARATOR in it by the cost of an additional (simple) input, this doesn't really solve the issue. After all, if we're assuming some user exists who has been using sending money, unspent, to scripts with OP_CODESEPARATOR to force signatures to commit to whether some other signature was present and who won't see a (invariably media-covered) pending soft-fork in time to claim their funds, we should also assume such a user has pre-signed transactions which are time-locked and claim a number of inputs and have several paths in the script which contain OP_CODESEPARATOR, rendering their transcription invalid.

Matt

> On Mar 11, 2019, at 15:15, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
> 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@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.”
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 4246 bytes --]