path: root/8e/0edcb083d78a822728ad5ccc8b8f057a25e833

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 BE65DB88
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 14:25:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-PU1-obe.outbound.protection.outlook.com
	(mail-oln040092254017.outbound.protection.outlook.com [40.92.254.17])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 960672D5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 14:25:50 +0000 (UTC)
Received: from PU1APC01FT041.eop-APC01.prod.protection.outlook.com
	(10.152.252.52) by PU1APC01HT242.eop-APC01.prod.protection.outlook.com
	(10.152.252.238) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19;
	Sun, 10 Mar 2019 14:25:47 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.52) by
	PU1APC01FT041.mail.protection.outlook.com (10.152.253.108) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
	15.20.1686.19 via Frontend Transport; Sun, 10 Mar 2019 14:25:47 +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;
	Sun, 10 Mar 2019 14:25:47 +0000
From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
	Consensus Cleanup
Thread-Index: AQHU1rw2k/hwC2uhP0aHjqncLGRJk6YE7Ftq
Date: Sun, 10 Mar 2019 14:25:47 +0000
Message-ID: <PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0@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>
In-Reply-To: <D631175F-0704-4820-BE3C-110E63F9E3FF@mattcorallo.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:121A48DA0934B6239BB724764119B64FCC0B5C90DBEB90D43AC93BCF95D440AD;
	UpperCasedChecksum:6558D1BE15C4A8AEDC5B7927C97CC9A507B9B92DC95A36CA00430F088CE3A09A;
	SizeAsReceived:7121; Count:44
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [tTkHqZ9z5xAGeQ3jH6cW6u/gnwcA1fJc]
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:PU1APC01HT242; 
x-ms-traffictypediagnostic: PU1APC01HT242:
x-microsoft-antispam-message-info: 5Xu6D8DQmz+kOS+cjmuqDF7KbaknDGlTgV5IY7csfNq54ErDuB/koyG47m1UfPv5
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0PS2P216MB0179KORP_"
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: eef88daa-1828-43ba-87de-08d6a5644a27
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2019 14:25:47.7900 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT242
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: Sun, 10 Mar 2019 14:55:12 +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 14:25:51 -0000

--_000_PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0PS2P216MB0179KORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


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 <bitcoin-dev-bounces@li=
sts.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 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> 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--_000_PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0PS2P216MB0179KORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<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)">
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div id=3D"signature">
<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>
<div id=3D"appendonsend"></div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> bitcoin-dev-bounces=
@lists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.or=
g&gt; on behalf of Matt Corallo via bitcoin-dev &lt;bitcoin-dev@lists.linux=
foundation.org&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"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"=
>
<div class=3D"PlainText">Aside from the complexity issues here, note that f=
or a user to be adversely affect, they probably have to have pre-signed loc=
k-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 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;sjors@sprovoost.nl&gt; wr=
ote:<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>
bitcoin-dev@lists.linuxfoundation.org<br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">=
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div>
</span></font></div>
</body>
</html>

--_000_PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0PS2P216MB0179KORP_--