From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 8 Mar 2019 20:12:29 +0100
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
	<CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
	<6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
	Russell O'Connor <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
Message-Id: <D2014BB7-1EFC-4604-ACF6-3C5AC74B6FC0@sprovoost.nl>
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
 Consensus Cleanup
Precedence: list


> (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.
>=20
>> 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.
>=20
> 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.

Although I'm not a fan of extra complicity, just to explore these two =
ideas a bit further.

What if such a transaction:

1. must have one input; and
2. must be smaller than 400 vbytes; and
3. must spend from a UTXO older than fork activation

Adding such a contextual check seems rather painful, perhaps comparable =
to nLockTime. Anything more specific than the above, e.g. counting the =
number of OP_CODESEPARATOR calls, seems like guess work.

Transaction weight currently doesn't consider OP codes, it only =
considers if bytes are part of the witness. Changing that to something =
more akin to Ethereums gas pricing sounds too complicated to even =
consider.


I would also like to believe that whoever went through the trouble of =
using OP_CODESEPARATOR reads this list.

Sjors