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>
	<PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
In-Reply-To: <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sun, 10 Mar 2019 11:22:44 -0400
Message-ID: <CAMZUoK=rUaJLKTD1X55xTfS0s_ps-PdwyxhBoUjQCo1UMn=c5g@mail.gmail.com>
To: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>
Content-Type: multipart/alternative; boundary="000000000000d014c70583bf07de"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
 Consensus Cleanup
Precedence: list

--000000000000d014c70583bf07de
Content-Type: text/plain; charset="UTF-8"

I fear that we cannot simply wait 10 years to address the vulnerability
that OP_CODESEPARATOR has in its current form.

On Fri, Mar 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH <
willtech@live.com.au> wrote:

> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
> ------------------------------
> *From:* bitcoin-dev-bounces@lists.linuxfoundation.org <
> bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Sjors
> Provoost via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 6:12 AM
> *To:* Matt Corallo; Russell O'Connor; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
>
> > (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.
>
> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">I fear that we cannot simply wait 10 years to address the =
vulnerability that OP_CODESEPARATOR has in its current form.<br></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar=
 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH &lt;<a href=3D"mailto:wi=
lltech@live.com.au">willtech@live.com.au</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">




<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
Opinion: Lock in a blockheight to get rid of it 10 years in the future. Use=
 it as press that Bitcoin is going to lose $1,000,000 if some mystery perso=
n does not put their transaction through by then, try for global presses. U=
se the opportunity to get rid of
 it while you are able. Once gazetted anything is public knowledge.<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
Regards,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
LORD HIS EXCELLENCY JAMES HRMH<br>
</div>
<div id=3D"gmail-m_7632206296970736518appendonsend"></div>
<hr style=3D"display:inline-block;width:98%">
<div id=3D"gmail-m_7632206296970736518divRplyFwdMsg" dir=3D"ltr"><font styl=
e=3D"font-size:11pt" face=3D"Calibri, sans-serif" color=3D"#000000"><b>From=
:</b> <a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev-bounces@lists.linuxfoundation.org</a> &lt;<a href=
=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev-bounces@lists.linuxfoundation.org</a>&gt; on behalf of Sjors P=
rovoost via bitcoin-dev
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
<b>Sent:</b> Saturday, 9 March 2019 6:12 AM<br>
<b>To:</b> Matt Corallo; Russell O&#39;Connor; Bitcoin Protocol Discussion<=
br>
<b>Subject:</b> Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Gr=
eat Consensus Cleanup</font>
<div>=C2=A0</div>
</div>
<div class=3D"gmail-m_7632206296970736518BodyFragment"><font size=3D"2"><sp=
an style=3D"font-size:11pt">
<div class=3D"gmail-m_7632206296970736518PlainText"><br>
&gt; (1) It has been well documented again and again that there is desire t=
o remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in no=
n-segwit scripts represents a rather significant vulnerability in Bitcoin t=
oday, and (3) lots of effort has gone
 into attempting to find practical use-cases for OP_CODESEPARATOR&#39;s spe=
cific construction, with no successes as of yet. I strongly, strongly disag=
ree that the highly-unlikely remote possibility that someone created someth=
ing before which could be rendered unspendable
 is sufficient reason to not fix a vulnerability in Bitcoin today.<br>
&gt; <br>
&gt;&gt; I suggest an alternative whereby the execution of OP_CODESEPARATOR=
 increases the transactions weight suitably as to temper the vulnerability =
caused by it.=C2=A0 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 t=
o why exceeding that limit isn&#39;t reasonable.<br>
&gt; <br>
&gt; You could equally argue, however, that any such limit could render som=
e moderately-large transaction unspendable, so I&#39;m somewhat skeptical o=
f this argument. Note that OP_CODESEPARATOR is non-standard, so getting the=
m mined is rather difficult in any case.<br>
<br>
Although I&#39;m not a fan of extra complicity, just to explore these two i=
deas a bit further.<br>
<br>
What if such a transaction:<br>
<br>
1. must have one input; and<br>
2. must be smaller than 400 vbytes; and<br>
3. must spend from a UTXO older than fork activation<br>
<br>
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.<br>
<br>
Transaction weight currently doesn&#39;t consider OP codes, it only conside=
rs if bytes are part of the witness. Changing that to something more akin t=
o Ethereums gas pricing sounds too complicated to even consider.<br>
<br>
<br>
I would also like to believe that whoever went through the trouble of using=
 OP_CODESEPARATOR reads this list.<br>
<br>
Sjors<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev</a><br>
</div>
</span></font></div>
</div>

</blockquote></div>

--000000000000d014c70583bf07de--