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>
In-Reply-To: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Fri, 8 Mar 2019 10:57:25 -0500
Message-ID: <CAMZUoKk3CgatSexAHRuxn3ibCYwgHpTkc0gF0yDi6hLAVcCiNA@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="00000000000018cebf05839748da"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
	Consensus Cleanup
Precedence: list

--00000000000018cebf05839748da
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> Replies inline.
>
> Matt
>
> On 3/7/19 3:03 PM, Russell O'Connor wrote:
> >
> >     * OP_CODESEPARATOR in non-BIP 143 scripts fails the script
> validation.
> >     This includes OP_CODESEPARATORs in unexecuted branches of if
> >     statements,
> >     similar to other disabled opcodes, but unlike OP_RETURN.
> >
> >
> > OP_CODESEPARATOR is the only mechanism available that allows users to
> > sign which particular branch they are authorizing for within scripts
> > that have multiple possible conditions that reuse the same public key.
>
> This is true, and yet it does not appear to actually be practically
> usable. Thus far, despite a ton of effort, I have not yet seen a
> practical use-case for OP_CODESEPARATOR (except for one example of it
> being used to make SegWit scripts ever-so-slightly more effecient in
> TumbleBit, hence why this BIP does not propose disabling it for SegWit).
>

It's very easy to construct a practical script using OP_CODESEPARATOR.

IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE CODESEPARATOR
<ALICEPUBKEY> CHECKSIGVERFY ENDIF

Now when someone hands Alice, the CFO of XYZ corp., some transaction, she
has the option of either signing it unilaterally herself, or creating a
partial signature such that the transaction additionally needs Bob, the
CEOs signature as well, and Alice's choice is committed to the blockchain
for auditing purposes later.

Now, there are many things you might object about this scheme, but my point
is that (A) regardless of what you think about this scheme, it, or similar
schemes, may have been devised by users, and (B) users may have already
committed funds to such schemes, and due to P2SH you cannot know that this
is not the case.


> > Because of P2SH you cannot know that no one is currently using this
> > feature.  Activating a soft-fork as describe above means these sorts of
> > funds would be permanently lost.  It is not acceptable to risk people's
> > money like this.
>
> (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.
>

Please don't strawman my position.  I am not suggesting we don't fix a
vulnerability in Bitcoin.  I am suggesting we find another way.  One that
limits the of risk destroying other people's money.

Here is a more concrete proposal:  No matter how bad OP_CODESEPARATOR is,
it cannot be worse than instead including another input that spends another
identically sized UTXO.  So how about we soft-fork in a rule that says that
an input's weight is increased by an amount equal to the number of
OP_CODESEPARATORs executed times the sum of weight of the UTXO being spent
and 40 bytes, the weight of a stripped input. The risk of destroying other
people's money is limited and AFAIU it would completely address the
vulnerabilities caused by OP_CODESEPARATOR.

Even soft forking a rule like, "it is illegal to execute an
OP_CODESEPARATOR after any CHECKSIG/CHECKMULTISIG operation", would be
vastly better than the current proposal, even though I would still object
to it.


> > 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.
>

I already know of people who's funds are tied up due to in other changes to
Bitcoin Core's default relay policy.  Non-standardness is not an excuse to
take other people's tied up funds and destroy them permanently.

There is some sort of crisis in the Bitcoin protocol stemming from the
possible excessive usage of OP_CODESEPARTOR otherwise we wouldn't even be
considering this soft fork.  Fine.  But presumably it is impossible for a
transaction to both be produced in good faith for legitimate use and at the
same time are expensive enough to be used as an attack vector, and
hopefully there is a wide gap between these two cases.  So let's draw a
line between the two cases to rule out attacks while allowing legitimate
uses by simply suitably pricing the OP_CODESEPARATOR opcode by weight.  At
worst case this moderately-large transaction is very expensive, reflecting
its true cost, or is was so expensive that it couldn't possibly have been
legitimate to begin with since the resources to validate it exceed the
amount that are reasonable to validate an entire block of regular
transactions.

--00000000000018cebf05839748da
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo &lt;<a href=3D"mailto:lf=
-lists@mattcorallo.com" target=3D"_blank">lf-lists@mattcorallo.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Replies i=
nline.<br>
<br>
Matt<br>
<br>
On 3/7/19 3:03 PM, Russell O&#39;Connor wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0* OP_CODESEPARATOR in non-BIP 143 scripts fails the=
 script validation.<br>
&gt;=C2=A0 =C2=A0 =C2=A0This includes OP_CODESEPARATORs in unexecuted branc=
hes of if<br>
&gt;=C2=A0 =C2=A0 =C2=A0statements,<br>
&gt;=C2=A0 =C2=A0 =C2=A0similar to other disabled opcodes, but unlike OP_RE=
TURN.<br>
&gt; <br>
&gt; <br>
&gt; OP_CODESEPARATOR is the only mechanism available that allows users to =
<br>
&gt; sign which particular branch they are authorizing for within scripts <=
br>
&gt; that have multiple possible conditions that reuse the same public key.=
<br>
<br>
This is true, and yet it does not appear to actually be practically <br>
usable. Thus far, despite a ton of effort, I have not yet seen a <br>
practical use-case for OP_CODESEPARATOR (except for one example of it <br>
being used to make SegWit scripts ever-so-slightly more effecient in <br>
TumbleBit, hence why this BIP does not propose disabling it for SegWit).<br=
></blockquote><div><br></div><div>It&#39;s very easy to construct a practic=
al script using OP_CODESEPARATOR.</div><div><br></div><div>IF &lt;2&gt; &lt=
;ALICEPUBKEY&gt; &lt;BOBPUBKEY&gt; &lt;2&gt; CHECKMULTISIGVERIFY ELSE CODES=
EPARATOR  &lt;ALICEPUBKEY&gt; CHECKSIGVERFY ENDIF<br></div><div><br></div><=
div>Now when someone hands Alice, the CFO of XYZ corp., some transaction, s=
he has the option of either signing it unilaterally herself, or creating a =
partial signature such that the transaction additionally needs Bob, the CEO=
s signature as well, and Alice&#39;s choice is committed to the blockchain =
for auditing purposes later.<br></div><div><br></div><div>Now, there are ma=
ny things you might object about this scheme, but my point is that (A) rega=
rdless of what you think about this scheme, it, or similar schemes, may hav=
e been devised by users, and (B) users may have already committed funds to =
such schemes, and due to P2SH you cannot know that this is not the case.<br=
></div><div>=C2=A0</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">
&gt; Because of P2SH you cannot know that no one is currently using this <b=
r>
&gt; feature.=C2=A0 Activating a soft-fork as describe above means these so=
rts of <br>
&gt; funds would be permanently lost.=C2=A0 It is not acceptable to risk pe=
ople&#39;s <br>
&gt; money like this.<br>
<br>
(1) It has been well documented again and again that there is desire to <br=
>
remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in <br>
non-segwit scripts represents a rather significant vulnerability in <br>
Bitcoin today, and (3) lots of effort has gone into attempting to find <br>
practical use-cases for OP_CODESEPARATOR&#39;s specific construction, with =
<br>
no successes as of yet. I strongly, strongly disagree that the <br>
highly-unlikely remote possibility that someone created something before <b=
r>
which could be rendered unspendable is sufficient reason to not fix a <br>
vulnerability in Bitcoin today.<br></blockquote><div><br></div><div>Please =
don&#39;t strawman my position.=C2=A0 I am not suggesting we don&#39;t fix =
a vulnerability in Bitcoin.=C2=A0 I am suggesting we find another way.=C2=
=A0 One that limits the of risk destroying other people&#39;s money.</div><=
div><br></div><div>Here is a more concrete proposal:=C2=A0 No matter how ba=
d OP_CODESEPARATOR is, it cannot be worse than instead including another in=
put that spends another identically sized UTXO.=C2=A0 So how about we soft-=
fork in a rule that says that an input&#39;s weight is increased by an amou=
nt equal to the number of OP_CODESEPARATORs executed times the sum of weigh=
t of the UTXO being spent and 40 bytes, the weight of a stripped input. The=
 risk of destroying other people&#39;s money is limited and AFAIU it would =
completely address the vulnerabilities caused by OP_CODESEPARATOR.</div><di=
v><br></div><div>Even soft forking a rule like, &quot;it is illegal to exec=
ute an OP_CODESEPARATOR after any CHECKSIG/CHECKMULTISIG operation&quot;, w=
ould be vastly better than the current proposal, even though I would still =
object to it.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">
&gt; I suggest an alternative whereby the execution of OP_CODESEPARATOR <br=
>
&gt; increases the transactions weight suitably as to temper the <br>
&gt; vulnerability caused by it.=C2=A0 Alternatively there could be some so=
rt of <br>
&gt; limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to =
be <br>
&gt; executed per script, but that would require an argument as to why <br>
&gt; exceeding that limit isn&#39;t reasonable.<br>
<br>
You could equally argue, however, that any such limit could render some <br=
>
moderately-large transaction unspendable, so I&#39;m somewhat skeptical of =
<br>
this argument. Note that OP_CODESEPARATOR is non-standard, so getting <br>
them mined is rather difficult in any case.<br></blockquote><div><br></div>=
<div>I already know of people who&#39;s funds are tied up due to in other c=
hanges to Bitcoin Core&#39;s default relay policy.=C2=A0 Non-standardness i=
s not an excuse to take other people&#39;s tied up funds and destroy them p=
ermanently.</div><br><div>There is some sort of crisis in the Bitcoin proto=
col stemming from the possible excessive usage of OP_CODESEPARTOR otherwise=
 we wouldn&#39;t even be considering this soft fork.=C2=A0 Fine.=C2=A0 But =
presumably it is impossible for a transaction to both be produced in good f=
aith for legitimate use and at the same time are expensive enough to be use=
d as an attack vector, and hopefully there is a wide gap between these two =
cases.=C2=A0 So let&#39;s draw a line between the two cases to rule out att=
acks while allowing legitimate uses by simply suitably pricing the OP_CODES=
EPARATOR opcode by weight.=C2=A0 At worst case this moderately-large transa=
ction is very expensive, reflecting its true cost, or is was so expensive t=
hat it couldn&#39;t possibly have been legitimate to begin with since the r=
esources to validate it exceed the amount that are reasonable to validate a=
n entire block of regular transactions.</div></div></div>

--00000000000018cebf05839748da--