Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F8FEAD7 for ; Tue, 12 Mar 2019 02:23:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9FED2C4 for ; Tue, 12 Mar 2019 02:23:35 +0000 (UTC) Received: from [30.91.248.69] (unknown [172.56.2.254]) by mail.bluematt.me (Postfix) with ESMTPSA id 7E7C01201F6; Tue, 12 Mar 2019 02:23:34 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2 Mime-Version: 1.0 (1.0) From: Matt Corallo X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Mon, 11 Mar 2019 22:23:33 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> To: Russell O'Connor , Bitcoin Protocol Discussion X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE 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 05:45:13 +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 02:23:37 -0000 --Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think you may have misunderstood part of the motivation. Yes, part of the m= otivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the= theoretical operation of checksig operations (thus somewhat simplifying the= implementation but also simplifying analysis of future changes, such as sig= hash-caching code). I think a key part of the analysis here is that no one I've spoken to (and w= e've been discussing removing it for *years*, including many attempts at com= ing up with reasons to keep it) is aware of any real proposals to use OP_COD= ESEPARATOR, let alone anyone using it in the wild. Hiding data in invalid pu= bic keys is a long-discussed-and-implemented idea (despite it's discourageme= nt, not to mention it appears on the chain in many places). It would end up being a huge shame to have all the OP_CORESEPARATOR mess lef= t around after all the effort that has gone into removing it for the past fe= w years, especially given the stark difference in visibility of a fork when c= ompared to a standardness change. As for your specific proposal of increasing the weight of anything that has a= n OP_CODESEPARATOR in it by the cost of an additional (simple) input, this d= oesn't really solve the issue. After all, if we're assuming some user exists= who has been using sending money, unspent, to scripts with OP_CODESEPARATOR= to force signatures to commit to whether some other signature was present a= nd who won't see a (invariably media-covered) pending soft-fork in time to c= laim their funds, we should also assume such a user has pre-signed transacti= ons which are time-locked and claim a number of inputs and have several path= s in the script which contain OP_CODESEPARATOR, rendering their transcriptio= n invalid. Matt > On Mar 11, 2019, at 15:15, Russell O'Connor via bitcoin-dev wrote: >=20 > Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size limi= t) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few more (o= verhead for varints) =3D 572ish bytes should be enough to completely elimina= te any vulnerability caused by OP_CODESEPARATOR within P2SH transactions wit= hout the need to remove it ever. I think it is worth attempting to be a bit= more clever than such a blunt rule, but it would be much better than elimin= ating OP_CODESEPARATOR within P2SH entirely. >=20 > Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goa= l is to eliminate the vulnerability associated with it. >=20 >> 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 tra= nsaction weight so using the op code is more expensive (10x, 20x?) and get t= he word out that it will be removed in the future. >>=20 >> You could even have nodes send a reject code with the message =E2=80=9COP= _CODESEPARATOR is depcrecated.=E2=80=9D > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I t= hink you may have misunderstood part of the motivation. Yes, part of the mot= ivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the t= heoretical operation of checksig operations (thus somewhat simplifying the i= mplementation but also simplifying analysis of future changes, such as sigha= sh-caching code).

I think a= key part of the analysis here is that no one I've spoken to (and we've been= discussing removing it for *years*, including many attempts at coming up wi= th reasons to keep it) is aware of any real proposals to use OP_CODESEPARATO= R, let alone anyone using it in the wild. Hiding data in invalid pubic keys i= s a long-discussed-and-implemented idea (despite it's discouragement, not to= mention it appears on the chain in many places).

=
It would end up being a huge shame to have all the OP= _CORESEPARATOR mess left around after all the effort that has gone into remo= ving it for the past few years, especially given the stark difference in vis= ibility of a fork when compared to a standardness change.

As for your specific proposal of increasing t= he weight of anything that has an OP_CODESEPARATOR in it by the cost of an a= dditional (simple) input, this doesn't really solve the issue. After all, if= we're assuming some user exists who has been using sending money, unspent, t= o scripts with OP_CODESEPARATOR to force signatures to commit to whether som= e other signature was present and who won't see a (invariably media-covered)= pending soft-fork in time to claim their funds, we should also assume such a= user has pre-signed transactions which are time-locked and claim a number o= f inputs and have several paths in the script which contain OP_CODESEPARATOR= , rendering their transcription invalid.

Matt

On Mar 11, 2019, at 15:15, Russ= ell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript s= ize limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few= more (overhead for varints) =3D 572ish bytes should be enough to completely= eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH transact= ions without the need to remove it ever.  I think it is worth attemptin= g to be a bit more clever than such a blunt rule, but it would be much bette= r than eliminating OP_CODESEPARATOR within P2SH entirely.

Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; th= e goal is to eliminate the vulnerability associated with it.
=
On Mon,= Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.= 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 node= s send a reject code with the message =E2=80=9COP_CODESEPARATOR is depcrecat= ed.=E2=80=9D
________= _______________________________________
bitcoin-dev mailing l= ist
bitcoin-dev@lists.linuxfoundation.org
https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2--