MIME-Version: 1.0
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>
	<FD3AE549-3DD4-48E0-9804-73BFBB30A9B0@mattcorallo.com>
In-Reply-To: <FD3AE549-3DD4-48E0-9804-73BFBB30A9B0@mattcorallo.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Tue, 12 Mar 2019 21:38:44 -0400
Message-ID: <CAMZUoK=NKfxMpDs18R1VUGg5YcwiTXUaTcE+H7RSArn0fBMjDw@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="00000000000072d15b0583efde8f"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
 Consensus Cleanup
Precedence: list

--00000000000072d15b0583efde8f
Content-Type: text/plain; charset="UTF-8"

Hi Matt,

On Mon, Mar 11, 2019 at 10:23 PM Matt Corallo <lf-lists@mattcorallo.com>
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

<div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"ltr"><div>Hi Matt,<br></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon=
, Mar 11, 2019 at 10:23 PM Matt Corallo &lt;<a href=3D"mailto:lf-lists@matt=
corallo.com" rel=3D"noreferrer" target=3D"_blank">lf-lists@mattcorallo.com<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">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).</div></div></blockquote><div><br></div><div>I see.=C2=A0 I was under=
 the mistaken impression the concerns about of OP_CODESEPARATOR was simply =
due to the vulnerability it induces.<br></div><div><br></div><div>I&#39;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 ce=
rtainly not a sufficient reason to remove usable op codes.<br></div><div><b=
r></div><div>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).</div=
><div><br></div><div>What I don&#39;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&#39;s the big=
 deal about flushing it during Script execution as well?<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto=
"><div dir=3D"ltr">I think a key part of the analysis here is that no one I=
&#39;ve spoken to (and we&#39;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&#39;s discouragement, not to mention it appears on the ch=
ain in many places).</div></div></blockquote><div><br></div><div>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.<br></div><div><br>=
</div><div>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?<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"auto"><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 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.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">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&#39=
;t really solve the issue. After all, if we&#39;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&#39;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.</div></div></blockquote><div><br></div><div>Agreed, t=
hat&#39;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.<br></div><div><br></div><div>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.<br></div></div></div></div>
</div>

--00000000000072d15b0583efde8f--