MIME-Version: 1.0
References: <CAD5xwhgXE9sB-hdzz_Bgz6iEA-M5-Yu2VOn1qRzkaq+DdVsgmw@mail.gmail.com>
 <RDWPxsOJbtO-irPtE3xbDy-jw58ApOT2LwumhVxGXC1NgkI43sUimoA2KYb-nsLPzz7kWgmf-p3YuPdok90EU1QNpW4hn5AihJvGV21_-xw=@protonmail.com>
In-Reply-To: <RDWPxsOJbtO-irPtE3xbDy-jw58ApOT2LwumhVxGXC1NgkI43sUimoA2KYb-nsLPzz7kWgmf-p3YuPdok90EU1QNpW4hn5AihJvGV21_-xw=@protonmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Sun, 6 Mar 2022 13:55:53 +0100
Message-ID: <CALxbBHWztmDGraRoJEzE2r8fJgSRh_0RBGiwKWmYaE92QEDzig@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000411e3f05d98c4560"
Subject: Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX,
 Turing Completeness, and other considerations
Precedence: list

--000000000000411e3f05d98c4560
Content-Type: text/plain; charset="UTF-8"

We'd have to be very carefully with this kind of third-party malleability,
since it'd make transaction pinning trivial without even requiring the
ability to spend one of the outputs (which current CPFP based pinning
attacks require).

Cheers,
Christian

On Sat, 5 Mar 2022, 00:33 ZmnSCPxj via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Jeremy,
>
> Umm `OP_ANNEX` seems boring ....
>
>
> > It seems like one good option is if we just go on and banish the
> OP_ANNEX. Maybe that solves some of this? I sort of think so. It definitely
> seems like we're not supposed to access it via script, given the quote from
> above:
> >
> > Execute the script, according to the applicable script rules[11], using
> the witness stack elements excluding the script s, the control block c, and
> the annex a if present, as initial stack.
> > If we were meant to have it, we would have not nixed it from the stack,
> no? Or would have made the opcode for it as a part of taproot...
> >
> > But recall that the annex is committed to by the signature.
> >
> > So it's only a matter of time till we see some sort of Cat and Schnorr
> Tricks III the Annex Edition that lets you use G cleverly to get the annex
> onto the stack again, and then it's like we had OP_ANNEX all along, or
> without CAT, at least something that we can detect that the value has
> changed and cause this satisfier looping issue somehow.
>
> ... Never mind I take that back.
>
> Hmmm.
>
> Actually if the Annex is supposed to be ***just*** for adding weight to
> the transaction so that we can do something like increase limits on SCRIPT
> execution, then it does *not* have to be covered by any signature.
> It would then be third-party malleable, but suppose we have a "valid"
> transaction on the mempool where the Annex weight is the minimum necessary:
>
> * If a malleated transaction has a too-low Annex, then the malleated
> transaction fails validation and the current transaction stays in the
> mempool.
> * If a malleated transaction has a higher Annex, then the malleated
> transaction has lower feerate than the current transaction and cannot evict
> it from the mempool.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">We&#39;d have to be very carefully with this kind of thir=
d-party malleability, since it&#39;d make transaction pinning trivial witho=
ut even requiring the ability to spend one of the outputs (which current CP=
FP based pinning attacks require).=C2=A0<div dir=3D"auto"><br></div><div di=
r=3D"auto">Cheers,</div><div dir=3D"auto">Christian</div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, 5 Mar 2022=
, 00:33 ZmnSCPxj via bitcoin-dev, &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">Good morning Jeremy,<br>
<br>
Umm `OP_ANNEX` seems boring ....<br>
<br>
<br>
&gt; It seems like one good option is if we just go on and banish the OP_AN=
NEX. Maybe that solves some of this? I sort of think so. It definitely seem=
s like we&#39;re not supposed to access it via script, given the quote from=
 above:<br>
&gt;<br>
&gt; Execute the script, according to the applicable script rules[11], usin=
g the witness stack elements excluding the script s, the control block c, a=
nd the annex a if present, as initial stack.<br>
&gt; If we were meant to have it, we would have not nixed it from the stack=
, no? Or would have made the opcode for it as a part of taproot...<br>
&gt;<br>
&gt; But recall that the annex is committed=C2=A0to by=C2=A0the signature.<=
br>
&gt;<br>
&gt; So it&#39;s only a matter of time till we see some sort of Cat and Sch=
norr Tricks III the Annex Edition that lets you use G cleverly to get the a=
nnex onto the stack again, and then it&#39;s like we had OP_ANNEX all along=
, or without CAT, at least something that we can detect that the value has =
changed and cause this satisfier looping issue somehow.<br>
<br>
... Never mind I take that back.<br>
<br>
Hmmm.<br>
<br>
Actually if the Annex is supposed to be ***just*** for adding weight to the=
 transaction so that we can do something like increase limits on SCRIPT exe=
cution, then it does *not* have to be covered by any signature.<br>
It would then be third-party malleable, but suppose we have a &quot;valid&q=
uot; transaction on the mempool where the Annex weight is the minimum neces=
sary:<br>
<br>
* If a malleated transaction has a too-low Annex, then the malleated transa=
ction fails validation and the current transaction stays in the mempool.<br=
>
* If a malleated transaction has a higher Annex, then the malleated transac=
tion has lower feerate than the current transaction and cannot evict it fro=
m the mempool.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000411e3f05d98c4560--