Content-Type: multipart/alternative;
	boundary=Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2
Mime-Version: 1.0 (1.0)
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAMZUoKkJY6UpN=OmOsR0tDAwLw++dYrZtuo_Vir-+DHrK3ckNg@mail.gmail.com>
Date: Mon, 11 Mar 2019 22:23:33 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <FD3AE549-3DD4-48E0-9804-73BFBB30A9B0@mattcorallo.com>
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>
	<D2014BB7-1EFC-4604-ACF6-3C5AC74B6FC0@sprovoost.nl>
	<D631175F-0704-4820-BE3C-110E63F9E3FF@mattcorallo.com>
	<PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<CABLeJxS1sK8x-dgkOJ5f4=vjB4xja6EVeca-aHbeqOyS7SwWWQ@mail.gmail.com>
	<CAMZUoKkJY6UpN=OmOsR0tDAwLw++dYrZtuo_Vir-+DHrK3ckNg@mail.gmail.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
Precedence: list


--Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think you may have misunderstood part of the motivation. Yes, part of the m=
otivation *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 sig=
hash-caching code).

I think a key part of the analysis here is that no one I've spoken to (and w=
e've been discussing removing it for *years*, including many attempts at com=
ing up with reasons to keep it) is aware of any real proposals to use OP_COD=
ESEPARATOR, let alone anyone using it in the wild. Hiding data in invalid pu=
bic keys is a long-discussed-and-implemented idea (despite it's discourageme=
nt, 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 lef=
t around after all the effort that has gone into removing it for the past fe=
w years, especially given the stark difference in visibility of a fork when c=
ompared to a standardness change.

As for your specific proposal of increasing the weight of anything that has a=
n OP_CODESEPARATOR in it by the cost of an additional (simple) input, this d=
oesn'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 a=
nd who won't see a (invariably media-covered) pending soft-fork in time to c=
laim their funds, we should also assume such a user has pre-signed transacti=
ons which are time-locked and claim a number of inputs and have several path=
s in the script which contain OP_CODESEPARATOR, rendering their transcriptio=
n invalid.

Matt

> On Mar 11, 2019, at 15:15, Russell O'Connor via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>=20
> Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size limi=
t) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few more (o=
verhead for varints) =3D 572ish bytes should be enough to completely elimina=
te any vulnerability caused by OP_CODESEPARATOR within P2SH transactions wit=
hout 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 elimin=
ating OP_CODESEPARATOR within P2SH entirely.
>=20
> Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goa=
l is to eliminate the vulnerability associated with it.
>=20
>> 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 tra=
nsaction weight so using the op code is more expensive (10x, 20x?) and get t=
he word out that it will be removed in the future.
>>=20
>> You could even have nodes send a reject code with the message =E2=80=9COP=
_CODESEPARATOR is depcrecated.=E2=80=9D
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">I t=
hink you may have misunderstood part of the motivation. Yes, part of the mot=
ivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the t=
heoretical operation of checksig operations (thus somewhat simplifying the i=
mplementation but also simplifying analysis of future changes, such as sigha=
sh-caching code).</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">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 wi=
th reasons to keep it) is aware of any real proposals to use OP_CODESEPARATO=
R, let alone anyone using it in the wild. Hiding data in invalid pubic keys i=
s a long-discussed-and-implemented idea (despite it's discouragement, not to=
 mention it appears on the chain in many places).</div><div dir=3D"ltr"><br>=
</div><div dir=3D"ltr">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 remo=
ving it for the past few years, especially given the stark difference in vis=
ibility of a fork when compared to a standardness change.</div><div dir=3D"l=
tr"><br></div><div dir=3D"ltr">As for your specific proposal of increasing t=
he weight of anything that has an OP_CODESEPARATOR in it by the cost of an a=
dditional (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, t=
o scripts with OP_CODESEPARATOR to force signatures to commit to whether som=
e 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 o=
f inputs and have several paths in the script which contain OP_CODESEPARATOR=
, rendering their transcription invalid.</div><div dir=3D"ltr"><br></div><di=
v dir=3D"ltr">Matt</div><div dir=3D"ltr"><br>On Mar 11, 2019, at 15:15, Russ=
ell O'Connor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></=
div><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"=
ltr"><div>Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript s=
ize limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few=
 more (overhead for varints) =3D 572ish bytes should be enough to completely=
 eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH transact=
ions without the need to remove it ever.&nbsp; I think it is worth attemptin=
g to be a bit more clever than such a blunt rule, but it would be much bette=
r than eliminating OP_CODESEPARATOR within P2SH entirely.</div><div><br></di=
v><div>Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; th=
e goal is to eliminate the vulnerability associated with it.<br></div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon,=
 Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div><div dir=3D"auto">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.</div>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">You could even have node=
s send a reject code with the message =E2=80=9COP_CODESEPARATOR is depcrecat=
ed.=E2=80=9D</div>
</blockquote></div></div>
</div></blockquote><blockquote type=3D"cite"><div dir=3D"ltr"><span>________=
_______________________________________</span><br><span>bitcoin-dev mailing l=
ist</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href=3D"https:=
//lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquot=
e></body></html>=

--Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2--