Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 45B058DC for ; Sun, 10 Mar 2019 15:22:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 72E3C832 for ; Sun, 10 Mar 2019 15:22:57 +0000 (UTC) Received: by mail-it1-f176.google.com with SMTP id l139so3447602ita.5 for ; Sun, 10 Mar 2019 08:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=giDBpypnFMphnYMJxIKEJFjgAOkzcmlkyaarqlEXFhQ=; b=S/FmCXZLJvBfqm33+FLi1YxFTc/D7kk2475cW2FViPYlOWr9GsFyxaHk0yG53f84yV 13EW4KDhF24F5ID2IrJZRtwJ9JQlpVwW1op2LsbtRxAID6+DiqvORN2m3bnVaQ2ho+cz 8yp3MidQXA8zJlOXiYbNk8bPEXVKyx038yBvo= 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:cc; bh=giDBpypnFMphnYMJxIKEJFjgAOkzcmlkyaarqlEXFhQ=; b=AUwO05S0M4h6OjRPto33sz6faOXlcFYr2uzWsBbePjU/gr1EETWlJXCvoR3LZKrvG7 LOnd13Ay9pUsfGfeDOhXxXEs5w4fQehGOIwL7HUpWz6vINpCt/zh0J42vWp2DH+vxUK6 HZW/6FtP4yaH4l23bX2wNrCXnfhUMqQUPr1YqrYK+hxKfWapr8fiO+p9r8KixP0bjYsA eL/HkdLUyyhGO6MQYA0771Wsv6IkLWSK6ywvFhLx7SBR3BCt9Atj2VnB+0mV4unfN8Ts lS82umkp9W0ITaXXfKTWb+ufC0jjLWVINFkpLq+BGM5QpyMeEt6PGUAFGtNJB33bRXkf c6Ow== X-Gm-Message-State: APjAAAUH2nMYhdL2P3OgpgUu+lSbB5+C7TprJ6nVFfy3k91pXCzV4eYl dLrHtzRAj4zMzNCPdQuETqDExHsdN8FLtVdEE3wB2w== X-Google-Smtp-Source: APXvYqz40yPzlrkx14OWNpWqssV97QmY+VP6XbdWTdU3DlcCzbLwRuclBzjJ37HDF/0lKMxV1U+9k7c77AIeu6+nPeo= X-Received: by 2002:a24:3a8b:: with SMTP id m133mr12847286itm.26.1552231376615; Sun, 10 Mar 2019 08:22:56 -0700 (PDT) MIME-Version: 1.0 References: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> In-Reply-To: From: "Russell O'Connor" Date: Sun, 10 Mar 2019 11:22:44 -0400 Message-ID: To: LORD HIS EXCELLENCY JAMES HRMH Content-Type: multipart/alternative; boundary="000000000000d014c70583bf07de" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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:23 +0000 Cc: Bitcoin Protocol Discussion 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 15:22:58 -0000 --000000000000d014c70583bf07de Content-Type: text/plain; charset="UTF-8" I fear that we cannot simply wait 10 years to address the vulnerability that OP_CODESEPARATOR has in its current form. On Fri, Mar 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH < willtech@live.com.au> 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 Sjors > Provoost via bitcoin-dev > *Sent:* Saturday, 9 March 2019 6:12 AM > *To:* Matt Corallo; Russell O'Connor; Bitcoin Protocol Discussion > *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great > Consensus Cleanup > > > > (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 > 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 some > moderately-large transaction unspendable, so I'm somewhat skeptical of this > argument. Note that OP_CODESEPARATOR is non-standard, so getting them 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 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 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 > --000000000000d014c70583bf07de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I fear that we cannot simply wait 10 years to address the = vulnerability that OP_CODESEPARATOR has in its current form.

<= div class=3D"gmail_quote">
On Fri, Mar= 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au> 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 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 Sjors P= rovoost via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Saturday, 9 March 2019 6:12 AM
To: Matt Corallo; Russell O'Connor; Bitcoin Protocol Discussion<= br> Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Gr= eat Consensus Cleanup
=C2=A0

> (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 no= n-segwit scripts represents a rather significant vulnerability in Bitcoin t= oday, and (3) lots of effort has gone into attempting to find practical use-cases for OP_CODESEPARATOR'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.
>
>> I suggest an alternative whereby the execution of OP_CODESEPARATOR= increases the transactions weight suitably as to temper the vulnerability = caused by it.=C2=A0 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 t= o 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 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 i= deas 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 conside= rs if bytes are part of the witness. Changing that to something more akin t= o 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
--000000000000d014c70583bf07de--