path: root/9f/c7080b7f3f3a21db513fe1d4f998bf67171e94

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 45B058DC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 15:22:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f176.google.com (mail-it1-f176.google.com
	[209.85.166.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 72E3C832
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 15:22:57 +0000 (UTC)
Received: by mail-it1-f176.google.com with SMTP id l139so3447602ita.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 08:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream.io; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=giDBpypnFMphnYMJxIKEJFjgAOkzcmlkyaarqlEXFhQ=;
	b=S/FmCXZLJvBfqm33+FLi1YxFTc/D7kk2475cW2FViPYlOWr9GsFyxaHk0yG53f84yV
	13EW4KDhF24F5ID2IrJZRtwJ9JQlpVwW1op2LsbtRxAID6+DiqvORN2m3bnVaQ2ho+cz
	8yp3MidQXA8zJlOXiYbNk8bPEXVKyx038yBvo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=giDBpypnFMphnYMJxIKEJFjgAOkzcmlkyaarqlEXFhQ=;
	b=AUwO05S0M4h6OjRPto33sz6faOXlcFYr2uzWsBbePjU/gr1EETWlJXCvoR3LZKrvG7
	LOnd13Ay9pUsfGfeDOhXxXEs5w4fQehGOIwL7HUpWz6vINpCt/zh0J42vWp2DH+vxUK6
	HZW/6FtP4yaH4l23bX2wNrCXnfhUMqQUPr1YqrYK+hxKfWapr8fiO+p9r8KixP0bjYsA
	eL/HkdLUyyhGO6MQYA0771Wsv6IkLWSK6ywvFhLx7SBR3BCt9Atj2VnB+0mV4unfN8Ts
	lS82umkp9W0ITaXXfKTWb+ufC0jjLWVINFkpLq+BGM5QpyMeEt6PGUAFGtNJB33bRXkf
	c6Ow==
X-Gm-Message-State: APjAAAUH2nMYhdL2P3OgpgUu+lSbB5+C7TprJ6nVFfy3k91pXCzV4eYl
	dLrHtzRAj4zMzNCPdQuETqDExHsdN8FLtVdEE3wB2w==
X-Google-Smtp-Source: APXvYqz40yPzlrkx14OWNpWqssV97QmY+VP6XbdWTdU3DlcCzbLwRuclBzjJ37HDF/0lKMxV1U+9k7c77AIeu6+nPeo=
X-Received: by 2002:a24:3a8b:: with SMTP id m133mr12847286itm.26.1552231376615;
	Sun, 10 Mar 2019 08:22:56 -0700 (PDT)
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"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, LOTS_OF_MONEY,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 11 Mar 2019 16:43:23 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
 Consensus Cleanup
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Mar 2019 15:22:58 -0000

--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--