From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B5A88DE1 for ; 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 ; 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 To: Moral Agent , Bitcoin Protocol Discussion , Moral Agent 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: References: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> , In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > = 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 > 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 > 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 > on behalf of Matt= Corallo via bitcoin-dev > 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 > 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --_000_PS2P216MB017993C1E1FE87B7AD9F88C69D490PS2P216MB0179KORP_ Content-Type: text/html; 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<= /span> via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:
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 mes= sage =93OP_CODESEPARATOR is depcrecated.=94
>Yes, that sort of thing, widely publicised. Positive = publicity is a good thing.


From: = Moral Agent via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org>
Sent: Monday, 11 March 20= 19 5:24 AM
To: LORD HIS EXCELLENCY JAMES HRMH; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Gr= eat Consensus 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 the 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 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.

On Sun, Mar 10, 2019 at 10:55 AM LO= RD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>= ; wrote:

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.
Reg= ards,
LOR= D HIS EXCELLENCY JAMES HRMH

Fr= om: bitcoin-dev-bounces@lists.linuxfoundation.org <bitco= in-dev-bounces@lists.linuxfoundation.org> on behalf of Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfound= ation.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 Gr= eat Consensus Cleanup
 
<= span style=3D"font-size:11pt">
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.

> 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 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.
>>
>>> 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.  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.
>>
>> 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.
>
> 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 comparabl= e to nLockTime. Anything more specific than the above, e.g. counting the nu= mber of OP_CODESEPARATOR calls, seems like guess work.
>
> 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.
>
>
> 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/bitcoi= n-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--_000_PS2P216MB017993C1E1FE87B7AD9F88C69D490PS2P216MB0179KORP_--