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 999B725A for ; Wed, 13 Mar 2019 01:38:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it1-f170.google.com (mail-it1-f170.google.com [209.85.166.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B62B7826 for ; Wed, 13 Mar 2019 01:38:56 +0000 (UTC) Received: by mail-it1-f170.google.com with SMTP id w18so367971itj.4 for ; Tue, 12 Mar 2019 18:38:56 -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=dLb+xG50xXNsCRy6bjr/uu2ampusVB1gjRCTy9ZU/Mc=; b=gNOj03R5KLq0oIiGQw+bbue/u7cE/4NExOhmRVdMRgLkKeuGCxO1CUrOgnS59ofWWd TDxnHV/bxxEAU70m1HsTC2kFKotEYdIJIwL2ejr771wRa2IaIeGRO2wPeo/HCBTUt4I3 cTDCcjEakotjQ7UmjKL3AbtaUhGuJEWmLDQC8= 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=dLb+xG50xXNsCRy6bjr/uu2ampusVB1gjRCTy9ZU/Mc=; b=Id7qmDwDlDxSiFMgqTU+OJaNFRvQzgQUyrhfqQjTVDg0aXHWoVU7N+mNu6zIFLjOcQ jCcPKutyFvg7iShnhcDjpz1YKXSY9MBCG2yzjJD/Q5OUGZWAOJugHTBOQuzJ7cr30j3I tOop4LkrNYSS6RPWA+sEjNP4W3y0N2je7/9/rfEe7G1H7yZvRCXulOZOlW4NeIdqJLGt sIk2Kugxysm0r6kYi1G46aN0MuVx4j4dsJVVgiiMRAbGhVuMBgb/nfcRc2RgQjDCJwCF aesdGsG+CyFj8aq3ZLn7WTr2oEe8xoTbBOy1C2b5bDNB0rzHuxmCviyL5x5rqiyV4yNK HIHw== X-Gm-Message-State: APjAAAXwHw94K25C2GVhuBFPlnZDUdeAredUxMkiedveWkPAzrW/C66d oy80opaYdEKJl80s1QqZfQY1sbZfmUM1dKuGJmMlGQ== X-Google-Smtp-Source: APXvYqz0vwZh4Oki4V9Kd1rQHLn7qS0eK6mhBJVZsOViX9cKbdDxNuyW//KTKqdXktIUwap+R+ztrPebLhUWyHFb7b4= X-Received: by 2002:a24:3a8b:: with SMTP id m133mr402479itm.26.1552441136037; Tue, 12 Mar 2019 18:38:56 -0700 (PDT) MIME-Version: 1.0 References: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> In-Reply-To: From: "Russell O'Connor" Date: Tue, 12 Mar 2019 21:38:44 -0400 Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary="00000000000072d15b0583efde8f" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, 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: Wed, 13 Mar 2019 06:46: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: Wed, 13 Mar 2019 01:38:57 -0000 --00000000000072d15b0583efde8f Content-Type: text/plain; charset="UTF-8" Hi Matt, On Mon, Mar 11, 2019 at 10:23 PM Matt Corallo wrote: > I think you may have misunderstood part of the motivation. Yes, part of > the motivation *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 sighash-caching code). > I see. I was under the mistaken impression the concerns about of OP_CODESEPARATOR was simply due to the vulnerability it induces. I'll say it now then: Simplifying the theoretical operation of Bitcoin is not a sufficient reason to make changes to the consensus rules, and it is most certainly not a sufficient reason to remove usable op codes. Had I understood that this was your motivation I would have presented my opinion earlier. I understand that the OP_CODESEPARATOR vulnerability is quite serious and making it non-standard while we address the problem is a good idea (hence the reason why I never objected before now). What I don't understand is why you feel that avoiding flushing the sigcache is so critical that you are willing to go through a risky consensus change just to achieve it? The sigcache is effectively flushed for each input of a transaction anyways, so what's the big deal about flushing it during Script execution as well? > 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 with reasons to keep it) is aware of any real proposals to use > OP_CODESEPARATOR, let alone anyone using it in the wild. Hiding data in > invalid pubic keys is a long-discussed-and-implemented idea (despite it's > discouragement, not to mention it appears on the chain in many places). > Well you've spoken to me now, and I believe I have given you good reasons to keep it. We all used to think that OP_CODESEPARATOR was a useless operation that no one in their right mind would ever use, but it turns out that we were wrong. Lesson learned. We should be more humble about considering these sorts of changes in the future because it seems we might not understand Bitcoin as well as we think we do. At the very least I was caught by surprise by the utility of OP_CODESEPARATOR. You misunderstand my point regarding invalid public keys. My point is that if no one has spoken up about the invalid public key issue on this mailing list, something that we know really does affects people, why do you expect that people would have spoken up about OP_CODESEPARATATOR affecting them? > 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 removing it for the > past few years, especially given the stark difference in visibility of a > fork when compared to a standardness change. > > As for your specific proposal of increasing the weight of anything that > has an OP_CODESEPARATOR in it by the cost of an additional (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, to scripts with > OP_CODESEPARATOR to force signatures to commit to whether some 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 > of inputs and have several paths in the script which contain > OP_CODESEPARATOR, rendering their transcription invalid. > Agreed, that's why we will want to not simply count the OP_CODESEPARATORS, but rather count the maximum number of OP_CODESEPARATORS that can be executed through the any of the various possible OP_IF branches. Adding this sort of control-flow analysis is a pretty simple. It just requires a small stack of pairs of numbers and linear traversal through the Script. This sort of OP_IF control flow analysis ought to have been done for counting CHECKSIG operations, but unfortunately it is too late for that now. I could prototype the sort of analysis I have in mind if you think that would be helpful. In fact, it is really alternating uses of OP_CODESEPARATOR and CheckSig operations that is problematic, so it is probably worth attempting to count these pairs rather than just OP_CODESEPARATORS. --00000000000072d15b0583efde8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Matt,
=
On Mon= , Mar 11, 2019 at 10:23 PM Matt Corallo <lf-lists@mattcorallo.com<= /a>> wrote:
<= div dir=3D"auto">
I think you may ha= ve misunderstood part of the motivation. Yes, part of the motivation *is* t= o remove OP_CODESEPARATOR wholesale, greatly simplifying the theoretical op= eration of checksig operations (thus somewhat simplifying the implementatio= n but also simplifying analysis of future changes, such as sighash-caching = code).


Had I understood that this was your motivation I would have pr= esented my opinion earlier. I understand that the OP_CODESEPARATOR vulnerab= ility is quite serious and making it non-standard while we address the prob= lem is a good idea (hence the reason why I never objected before now).

What I don't understand is why you feel that avoid= ing flushing the sigcache is so critical that you are willing to go through= a risky consensus change just to achieve it?=C2=A0 The sigcache is effecti= vely flushed for each input of a transaction anyways, so what's the big= deal about flushing it during Script execution as well?
=C2= =A0
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*, i= ncluding many attempts at coming up with reasons to keep it) is aware of an= y real proposals to use OP_CODESEPARATOR, let alone anyone using it in the = wild. Hiding data in invalid pubic keys is a long-discussed-and-implemented= idea (despite it's discouragement, not to mention it appears on the ch= ain in many places).

Well you&#= 39;ve spoken to me now, and I believe I have given you good reasons to keep= it.=C2=A0 We all used to think that OP_CODESEPARATOR was a useless operati= on that no one in their right mind would ever use, but it turns out that we= were wrong.=C2=A0 Lesson learned.=C2=A0 We should be more humble about con= sidering these sorts of changes in the future because it seems we might not= understand Bitcoin as well as we think we do.=C2=A0 At the very least I wa= s caught by surprise by the utility of OP_CODESEPARATOR.

=
You misunderstand my point regarding invalid public keys.=C2=A0 = My point is that if no one has spoken up about the invalid public key issue= on this mailing list, something that we know really does affects people, w= hy do you expect that people would have spoken up about OP_CODESEPARATATOR = affecting them?
=C2=A0
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 removing it for the past few years, especially g= iven the stark difference in visibility of a fork when compared to a standa= rdness change.

As for your= specific proposal of increasing the weight of anything that has an OP_CODE= SEPARATOR in it by the cost of an additional (simple) input, this doesn'= ;t really solve the issue. After all, if we're assuming some user exist= s who has been using sending money, unspent, to scripts with OP_CODESEPARAT= OR to force signatures to commit to whether some other signature was presen= t and who won't see a (invariably media-covered) pending soft-fork in t= ime to claim their funds, we should also assume such a user has pre-signed = transactions which are time-locked and claim a number of inputs and have se= veral paths in the script which contain OP_CODESEPARATOR, rendering their t= ranscription invalid.

Agreed, t= hat's why we will want to not simply count the OP_CODESEPARATORS, but r= ather count the maximum number of OP_CODESEPARATORS that can be executed th= rough the any of the various possible OP_IF branches.=C2=A0 Adding this sor= t of control-flow analysis is a pretty simple. It just requires a small sta= ck of pairs of numbers and linear traversal through the Script.=C2=A0 This = sort of OP_IF control flow analysis ought to have been done for counting CH= ECKSIG operations, but unfortunately it is too late for that now.=C2=A0 I c= ould prototype the sort of analysis I have in mind if you think that would = be helpful.

In fact, it is really alternating = uses of OP_CODESEPARATOR and CheckSig operations that is problematic, so it= is probably worth attempting to count these pairs rather than just OP_CODE= SEPARATORS.
--00000000000072d15b0583efde8f--