MIME-Version: 1.0
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>
In-Reply-To: <CABLeJxS1sK8x-dgkOJ5f4=vjB4xja6EVeca-aHbeqOyS7SwWWQ@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 11 Mar 2019 15:15:38 -0400
Message-ID: <CAMZUoKkJY6UpN=OmOsR0tDAwLw++dYrZtuo_Vir-+DHrK3ckNg@mail.gmail.com>
To: Dustin Dettmer <dustinpaystaxes@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008ca8d30583d66624"
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
 Consensus Cleanup
Precedence: list

--0000000000008ca8d30583d66624
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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) =3D 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
> =E2=80=9COP_CODESEPARATOR is depcrecated.=E2=80=9D
>

--0000000000008ca8d30583d66624
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Increasing the OP_CODESEPARATOR weig=
ht by 520 (p2sh redeemScript size limit) + 40 (stripped txinput size) + 8 (=
stripped txoutput size) + a few more (overhead for varints) =3D 572ish byte=
s should be enough to completely eliminate any vulnerability caused by OP_C=
ODESEPARATOR within P2SH transactions without the need to remove it ever.=
=C2=A0 I think it is worth attempting to be a bit more clever than such a b=
lunt rule, but it would be much better than eliminating OP_CODESEPARATOR wi=
thin P2SH entirely.</div><div><br></div><div>Remember that the goal isn&#39=
;t to eliminate OP_CODESEPARATOR per se; the goal is to eliminate the vulne=
rability 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 Dust=
in Dettmer via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir=3D"auto">Wh=
at about putting it in a deprecated state for some time. Adjust the transac=
tion 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 nodes send a reject code =
with the message =E2=80=9COP_CODESEPARATOR is depcrecated.=E2=80=9D</div>
</blockquote></div></div>

--0000000000008ca8d30583d66624--