Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BE65DB88 for ; 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 ; 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 To: Bitcoin Protocol Discussion 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: 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: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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 --_000_PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0PS2P216MB0179KORP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

From: bitcoin-dev-bounces= @lists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.or= g> on behalf of Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linux= foundation.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
 
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.

> On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost.nl> wr= ote:
>
>
>> (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/bitcoin-dev
--_000_PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0PS2P216MB0179KORP_--