path: root/76/44757d82671ce52f9daa2925fbcfc89828ff3b

Return-Path: <willtech@live.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B5A88DE1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Mar 2019 07:35:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-PU1-obe.outbound.protection.outlook.com
	(mail-oln040092254088.outbound.protection.outlook.com [40.92.254.88])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F1ED62D5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Mar 2019 07:34:58 +0000 (UTC)
Received: from SG2APC01FT112.eop-APC01.prod.protection.outlook.com
	(10.152.250.60) by SG2APC01HT019.eop-APC01.prod.protection.outlook.com
	(10.152.251.58) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1686.19;
	Tue, 12 Mar 2019 07:34:55 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.250.60) by
	SG2APC01FT112.mail.protection.outlook.com (10.152.250.201) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
	15.20.1686.19 via Frontend Transport; Tue, 12 Mar 2019 07:34:55 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM
	([fe80::3c00:3d71:da44:2543]) by PS2P216MB0179.KORP216.PROD.OUTLOOK.COM
	([fe80::3c00:3d71:da44:2543%11]) with mapi id 15.20.1686.021;
	Tue, 12 Mar 2019 07:34:55 +0000
From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>
To: Moral Agent <ethan.scruples@gmail.com>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>, Moral Agent
	<ethan.scruples@gmail.com>
Thread-Topic: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
	Consensus Cleanup
Thread-Index: AQHU1259cblI425/J02WuVKFoHjnJqYHmYxr
Date: Tue, 12 Mar 2019 07:34:55 +0000
Message-ID: <PS2P216MB017993C1E1FE87B7AD9F88C69D490@PS2P216MB0179.KORP216.PROD.OUTLOOK.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>,
	<CACiOHGyJ9WZhp2HG1GJdfmkD-nUTFaeVevDJFVRB_j7yBSt6Ew@mail.gmail.com>
In-Reply-To: <CACiOHGyJ9WZhp2HG1GJdfmkD-nUTFaeVevDJFVRB_j7yBSt6Ew@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:645066C8EE85F7F86C770C0CFFE426C92DD7AD5647F0FEFCFB62F8CB33FA62A4;
	UpperCasedChecksum:3FEC1D7E6123E95B43635E3E06AD625E02DEE5A56FA43FA08F30420C09AECC79;
	SizeAsReceived:7402; Count:44
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [pOrR0AoXZVc5ItUd9gk2sTbSrKyMfhqR]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0;
	RULEID:(2390118)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045);
	SRVR:SG2APC01HT019; 
x-ms-traffictypediagnostic: SG2APC01HT019:
x-microsoft-antispam-message-info: 9TcHcCS59ekgKZoSB5AXdkmOhLumFK7u6yOAk+m71I/YCRG//7i60lX+eW9vK7u+
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB017993C1E1FE87B7AD9F88C69D490PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d18bac71-1fdb-462d-5fee-08d6a6bd3906
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 07:34:55.2320 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT019
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Tue, 12 Mar 2019 22:13:28 +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: Tue, 12 Mar 2019 07:35:00 -0000

--_000_PS2P216MB017993C1E1FE87B7AD9F88C69D490PS2P216MB0179KORP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I have not seen all of the emails in reply come through on the mailing list=
, I am sure it is always that way. There are a couple to reply to, replies =
indented>:

On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> =
wrote:
What about putting it in a deprecated state for some time. Adjust the trans=
action weight so using the op code is more expensive (10x, 20x?) and get th=
e word out that it will be removed in the future.

You could even have nodes send a reject code with the message =93OP_CODESEP=
ARATOR is depcrecated.=94
>Yes, that sort of thing, widely publicised. Positive publicity is a good t=
hing.


From: Moral Agent via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<ma=
ilto:bitcoin-dev@lists.linuxfoundation.org>>
Sent: Monday, 11 March 2019 5:24 AM
To: LORD HIS EXCELLENCY JAMES HRMH; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Con=
sensus Cleanup

>Lock in a blockheight to get rid of it 10 years in the future.

And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to t=
he soft fork activation standard, with weight penalties as appropriate, so =
there would be no difficulty spending them before the cutoff?
>Yes, precisely that sort of thing so that there is no difficulty spending =
the UTXOs before the cutoff, preferably we would never prevent spending exi=
sting valid transactions in the blockchain, also not only to morally discou=
rage the creation of new transactions with OP_CODESEAPRATOR but to physical=
ly prevent them if possible. At the minimum, 10 years of depreciated notifi=
cations should be enough for anyone but pre-signed lock-timed transactions =
may be a different matter. Do we currently allow them to be mined and the U=
TXO's not valid to be spent until n height/time? We should.

On Sun, Mar 10, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin=
-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxf=
oundation.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 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 anyth=
ing is public knowledge.

Regards,
LORD HIS EXCELLENCY JAMES HRMH

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org<mailto:bitcoin-dev-boun=
ces@lists.linuxfoundation.org> <bitcoin-dev-bounces@lists.linuxfoundation.o=
rg<mailto:bitcoin-dev-bounces@lists.linuxfoundation.org>> on behalf of Matt=
 Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitc=
oin-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 Con=
sensus 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. Oth=
erwise, in the crazy case that such a user exists, they should have no prob=
lem claiming the funds before activation of a soft-fork (and just switching=
 to the swgwit equivalent, or some other equivalent scheme). Thus, adding a=
dditional restrictions like tx size limits will equally break txn.

> On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost.nl<mailto:sjors=
@sprovoost.nl>> wrote:
>
>
>> (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 tod=
ay, and (3) lots of effort has gone into attempting to find practical use-c=
ases for OP_CODESEPARATOR's specific construction, with no successes as of =
yet. I strongly, strongly disagree that the highly-unlikely remote possibil=
ity that someone created something before which could be rendered unspendab=
le is sufficient reason to not fix a vulnerability in Bitcoin today.
>>
>>> I suggest an alternative whereby the execution of OP_CODESEPARATOR incr=
eases the transactions weight suitably as to temper the vulnerability cause=
d 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 reasona=
ble.
>>
>> 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 mine=
d is rather difficult in any case.
>
> Although I'm not a fan of extra complicity, just to explore these two ide=
as 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 t=
o nLockTime. Anything more specific than the above, e.g. counting the numbe=
r 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 usi=
ng OP_CODESEPARATOR reads this list.
>
> Sjors
>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--_000_PS2P216MB017993C1E1FE87B7AD9F88C69D490PS2P216MB0179KORP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
I have not seen all of the emails in reply come through on the mailing list=
, I am sure it is always that way. There are a couple to reply to, replies =
indented&gt;:</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<blockquote type=3D"cite" style=3D"margin-top: 0px; margin-bottom: 0px;">
<div dir=3D"ltr">
<div dir=3D"ltr">
<div>
<div dir=3D"ltr">On Mon, Mar 11, 2019 at 12:47 PM <span style=3D"background=
-color:yellow; color:black">
Dustin</span> <span style=3D"background-color:yellow; color:black">Dettmer<=
/span> via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank" rel=3D"noopener noreferrer">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt; wrote:<br>
</div>
<blockquote style=3D"margin:0 0 0 0.8ex; padding-left:1ex; border-left:1px =
solid #CCCCCC">
<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 nodes send a reject code with the mes=
sage =93OP_CODESEPARATOR is depcrecated.=94</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<div dir=3D"ltr">
<div dir=3D"ltr">
<div>
<div dir=3D"auto">&gt;Yes, that sort of thing, widely publicised. Positive =
publicity is a good thing.<br>
</div>
</div>
</div>
</div>
<blockquote type=3D"cite" style=3D"margin-top: 0px; margin-bottom: 0px;">
<div dir=3D"ltr">
<div dir=3D"ltr">
<div>
<blockquote style=3D"margin:0 0 0 0.8ex; padding-left:1ex; border-left:1px =
solid #CCCCCC">
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<blockquote style=3D"margin-top: 0px; margin-bottom: 0px;"><font style=3D"f=
ont-size:11pt" face=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> =
Moral Agent via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank" rel=3D"noopener noreferrer">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt;</font><br>
</blockquote>
<blockquote style=3D"margin-top: 0px; margin-bottom: 0px;">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>Sent:</b> Monday, 11 March 20=
19 5:24 AM<br>
<b>To:</b> LORD HIS EXCELLENCY JAMES HRMH; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Gr=
eat Consensus Cleanup</font>
<div>&nbsp;</div>
</div>
<div dir=3D"ltr"><span style=3D"color:rgb(0,0,0); font-family:Calibri,Helve=
tica,sans-serif,serif,EmojiFont; font-size:16px">&gt;Lock in a blockheight =
to get rid of it 10 years in the future.</span><br>
<div><br>
</div>
<div>And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior=
 to the soft fork activation standard, with weight penalties as appropriate=
, so there would be no difficulty spending them before the cutoff?</div>
</div>
</blockquote>
<div dir=3D"ltr">
<div>&gt;Yes, precisely that sort of thing so that there is no difficulty s=
pending the UTXOs before the cutoff, preferably we would never prevent spen=
ding existing valid transactions in the blockchain, also not only to morall=
y discourage the creation of new transactions
 with OP_CODESEAPRATOR but to physically prevent them if possible. At the m=
inimum, 10 years of depreciated notifications should be enough for anyone b=
ut pre-signed lock-timed transactions may be a different matter. Do we curr=
ently allow them to be mined and
 the UTXO's not valid to be spent until n height/time? We should.<br>
</div>
</div>
<blockquote style=3D"margin-top: 0px; margin-bottom: 0px;">
<div dir=3D"ltr"></div>
<br>
<div dir=3D"ltr" class=3D"x_gmail_attr">On Sun, Mar 10, 2019 at 10:55 AM LO=
RD HIS EXCELLENCY JAMES HRMH via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; wrote:<br>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; bord=
er-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div id=3D"x_gmail-m_7060861672063576034signature">
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<div>
<div>
<div>
<div dir=3D"ltr">
<div style=3D"color:black; font-size:12pt; font-family:Calibri,Helvetica,sa=
ns-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>
<hr style=3D"display:inline-block; width:98%">
<div id=3D"x_gmail-m_7060861672063576034divRplyFwdMsg" dir=3D"ltr"><font st=
yle=3D"font-size:11pt" face=3D"Calibri, sans-serif" color=3D"#000000"><b>Fr=
om:</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-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.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>&nbsp;</div>
</div>
<div class=3D"x_gmail-m_7060861672063576034BodyFragment"><font size=3D"2"><=
span style=3D"font-size:11pt">
<div class=3D"x_gmail-m_7060861672063576034PlainText">Aside from the comple=
xity issues here, note that for a user to be adversely affect, they probabl=
y 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-fork=
 (and just switching to the swgwit equivalent, or some other equivalent sch=
eme). Thus, adding additional restrictions 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's specifi=
c 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.<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.&nbsp; 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'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'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>
&gt; <br>
&gt; Although I'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't consider OP codes, it only consid=
ers if bytes are part of the witness. Changing that to something more akin =
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>
</blockquote>
<div>
<div class=3D"x_gmail_quote"></div>
</div>
</body>
</html>

--_000_PS2P216MB017993C1E1FE87B7AD9F88C69D490PS2P216MB0179KORP_--