Return-Path: <lf-lists@mattcorallo.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F8FEAD7 for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <lf-lists@mattcorallo.com> X-Mailer: iPhone Mail (16D57) In-Reply-To: <CAMZUoKkJY6UpN=OmOsR0tDAwLw++dYrZtuo_Vir-+DHrK3ckNg@mail.gmail.com> Date: Mon, 11 Mar 2019 22:23:33 -0400 Content-Transfer-Encoding: 7bit Message-Id: <FD3AE549-3DD4-48E0-9804-73BFBB30A9B0@mattcorallo.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> <PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM> <CABLeJxS1sK8x-dgkOJ5f4=vjB4xja6EVeca-aHbeqOyS7SwWWQ@mail.gmail.com> <CAMZUoKkJY6UpN=OmOsR0tDAwLw++dYrZtuo_Vir-+DHrK3ckNg@mail.gmail.com> To: Russell O'Connor <roconnor@blockstream.io>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 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 <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: 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 <bitcoin-dev@l= ists.linuxfoundation.org> 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 <bitcoin-= dev@lists.linuxfoundation.org> 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 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">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).</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">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).</div><div dir=3D"ltr"><br>= </div><div dir=3D"ltr">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.</div><div dir=3D"l= tr"><br></div><div dir=3D"ltr">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.</div><div dir=3D"ltr"><br></div><di= v dir=3D"ltr">Matt</div><div dir=3D"ltr"><br>On Mar 11, 2019, at 15:15, Russ= ell O'Connor via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfo= undation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br></= div><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"= ltr"><div>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.</div><div><br></di= v><div>Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; th= e goal is to eliminate the vulnerability associated with it.<br></div></div>= <br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon,= Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <<a href=3D"mail= to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.= org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"= ><div><div dir=3D"auto">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.</div>= </div><div dir=3D"auto"><br></div><div dir=3D"auto">You could even have node= s send a reject code with the message =E2=80=9COP_CODESEPARATOR is depcrecat= ed.=E2=80=9D</div> </blockquote></div></div> </div></blockquote><blockquote type=3D"cite"><div dir=3D"ltr"><span>________= _______________________________________</span><br><span>bitcoin-dev mailing l= ist</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"= >bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href=3D"https:= //lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquot= e></body></html>= --Apple-Mail-9F460C8B-1B0B-4AAB-92FB-8C922259EAE2--