path: root/88/1d86c2868872c6d8e1446efc31f7b53dfe96c0

Return-Path: <dustinpaystaxes@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A5A6A5E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 18:28:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com
	[209.85.128.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5309C2D5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 18:28:39 +0000 (UTC)
Received: by mail-wm1-f45.google.com with SMTP id n19so2239652wmi.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 11:28:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=mmjS3JNwSyQqnxh4KgW2dqnI5tjSioGT5L0lnTII3HE=;
	b=oJ01Iu5GggBrvrzaHZ2YCw+QJcc4PzmgHW16jtVBv1DqB7BnxQGzIPOlD/zru1JM5s
	Lx3mOiH8ST6sjwjfY7Wpy7shdtLGIKytHsw0B0Si5eIS5F5g7aQFVM3LVKDXEhYFAWDM
	PjaYtNdcH0xYXK25kfgF0/1wAcLhnNv4B7z64XJh9bMz/uXEmhhTMhM0V1U4b1wI8g9/
	c/38J0djMsa/3YfOarHlvLPU4WWY30zvPecXUq8ioJTZbCnJ6qpz01izt1aeJRQzOFJ2
	E6SIwkvreOSM/Av+yrhAYCs21J39qZM0V7Sfvjc3wIe5SO0xBSlEDc7fWg/JxtIiEn0W
	MkBg==
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;
	bh=mmjS3JNwSyQqnxh4KgW2dqnI5tjSioGT5L0lnTII3HE=;
	b=adpkCW3TVBhfUFL3xKXdJRzUAFPsq2EeMCryre6WLjYBdbCxwMMCP370m4RofibVjh
	wgEOls6HygtQM0wo/iOR6lcjT1Ccho0N6G9j+CCSigVdZS5sawTe/o+quHjbJ/nniYma
	gUuwTlfQkyxxT0eTQ5l5FbXAI494QLjJphRgNxX8qnjXExMdcC+lTB55ZP6u8KV/JOMS
	9ZVaGdcL8RGEj6oeqQp7gYHUKJGXlB4x/CrySHqR4twVD3VDM7bko8PiBAfVdMt8dIKw
	iWIozqcxIE6ETT+zg9V5BsIZpRgKI+vjw4sGM71H46LSSpImQZQrLyCi3B5mrnBIx1jY
	Ym/A==
X-Gm-Message-State: APjAAAVh9kfkRwGpoO3bteaFgkegapB4SdZyc1KnK7H01aJwqj7KBi50
	ULRa+0sFAM/2lrK3PgvgWFE8UC8o+QN5SZYc21TcoA==
X-Google-Smtp-Source: APXvYqzE0E75LooDeRiIb3aI+/KFeGLS0NpwOL/Q80mJ7xxEgZYb7+X8HE9fuziGe66vHkbb4c0ULYp06SgT1L+THNU=
X-Received: by 2002:a1c:e910:: with SMTP id q16mr15825747wmc.30.1552242517473; 
	Sun, 10 Mar 2019 11:28:37 -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>
	<D631175F-0704-4820-BE3C-110E63F9E3FF@mattcorallo.com>
	<PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
In-Reply-To: <PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
From: Dustin Dettmer <dustinpaystaxes@gmail.com>
Date: Sun, 10 Mar 2019 11:28:25 -0700
Message-ID: <CABLeJxS1sK8x-dgkOJ5f4=vjB4xja6EVeca-aHbeqOyS7SwWWQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000dbfe320583c19f01"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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:37 +0000
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 18:28:40 -0000

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

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

On Sun, Mar 10, 2019 at 7:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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 Matt Corallo
> via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 7:14 AM
> *To:* Sjors Provoost
> *Cc:* Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
> Aside from the complexity issues here, note that for a user to be
> adversely affect, they probably have to have pre-signed lock-timed
> transactions. Otherwise, in the crazy case that such a user exists, they
> should have no problem claiming the funds before activation of a soft-for=
k
> (and just switching to the swgwit equivalent, or some other equivalent
> scheme). Thus, adding additional restrictions like tx size limits will
> equally break txn.
>
> > On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost.nl> wrote:
> >
> >
> >> (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
> non-segwit scripts represents a rather significant vulnerability in Bitco=
in
> 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 som=
e
> moderately-large transaction unspendable, so I'm somewhat skeptical of th=
is
> argument. Note that OP_CODESEPARATOR is non-standard, so getting them min=
ed
> 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 mo=
re
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<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.</d=
iv></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 depc=
recated.=E2=80=9D</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Sun, Mar 10, 2019 at 7:55 AM LORD HIS EXCELLENCY J=
AMES HRMH via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">




<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
<br>
</div>
<div id=3D"m_4635703046407541515signature">
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
<div>
<div>
<div>
<div dir=3D"ltr">
<div style=3D"color:black;font-size:12pt;font-family:Calibri,Helvetica,sans=
-serif,serif,EmojiFont">
<div style=3D"font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont">Opi=
nion: 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 d=
oes not put their transaction through
 by then, try for global presses. Use the opportunity to get rid of it whil=
e you are able. Once gazetted anything is public knowledge.<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont"><br=
>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont">Reg=
ards,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont">LOR=
D HIS EXCELLENCY JAMES HRMH</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<div id=3D"m_4635703046407541515appendonsend"></div>
<hr style=3D"display:inline-block;width:98%">
<div id=3D"m_4635703046407541515divRplyFwdMsg" dir=3D"ltr"><font style=3D"f=
ont-size:11pt" face=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> =
<a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev-bounces@lists.linuxfoundation.org</a> &lt;<a href=3D"ma=
ilto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev-bounces@lists.linuxfoundation.org</a>&gt; on behalf of Matt Corallo =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
<b>Sent:</b> Saturday, 9 March 2019 7:14 AM<br>
<b>To:</b> Sjors Provoost<br>
<b>Cc:</b> 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><div dir=3D"ltr">
<div class=3D"m_4635703046407541515BodyFragment"><font size=3D"2"><span sty=
le=3D"font-size:11pt">
<div class=3D"m_4635703046407541515PlainText">Aside from the complexity iss=
ues here, note that for a user to be adversely affect, they probably have t=
o have pre-signed lock-timed transactions. Otherwise, in the crazy case tha=
t such a user exists, they should have no problem claiming
 the funds before activation of a soft-fork (and just switching to the swgw=
it equivalent, or some other equivalent scheme). Thus, adding additional re=
strictions like tx size limits will equally break txn.<br>
<br>
&gt; On Mar 8, 2019, at 14:12, Sjors Provoost &lt;<a href=3D"mailto:sjors@s=
provoost.nl" target=3D"_blank">sjors@sprovoost.nl</a>&gt; wrote:<br>
&gt; <br>
&gt; <br>
&gt;&gt; (1) It has been well documented again and again that there is desi=
re to remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR i=
n non-segwit scripts represents a rather significant vulnerability in Bitco=
in today, 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;&gt; <br>
&gt;&gt;&gt; I suggest an alternative whereby the execution of OP_CODESEPAR=
ATOR increases the transactions weight suitably as to temper the vulnerabil=
ity caused by it.=C2=A0 Alternatively there could be some sort of limit (ma=
ybe 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;&gt; <br>
&gt;&gt; You could equally argue, however, that any such limit could render=
 some moderately-large transaction unspendable, so I&#39;m somewhat skeptic=
al of this argument. Note that OP_CODESEPARATOR is non-standard, so getting=
 them mined is rather difficult in any case.<br>
&gt; <br>
&gt; Although I&#39;m not a fan of extra complicity, just to explore these =
two ideas a bit further.<br>
&gt; <br>
&gt; What if such a transaction:<br>
&gt; <br>
&gt; 1. must have one input; and<br>
&gt; 2. must be smaller than 400 vbytes; and<br>
&gt; 3. must spend from a UTXO older than fork activation<br>
&gt; <br>
&gt; Adding such a contextual check seems rather painful, perhaps comparabl=
e to nLockTime. Anything more specific than the above, e.g. counting the nu=
mber of OP_CODESEPARATOR calls, seems like guess work.<br>
&gt; <br>
&gt; Transaction weight currently doesn&#39;t consider OP codes, it only co=
nsiders if bytes are part of the witness. Changing that to something more a=
kin to Ethereums gas pricing sounds too complicated to even consider.<br>
&gt; <br>
&gt; <br>
&gt; I would also like to believe that whoever went through the trouble of =
using OP_CODESEPARATOR reads this list.<br>
&gt; <br>
&gt; Sjors<br>
&gt; <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>

_______________________________________________<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" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000dbfe320583c19f01--