Date: Fri, 04 Mar 2022 23:33:10 +0000
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <RDWPxsOJbtO-irPtE3xbDy-jw58ApOT2LwumhVxGXC1NgkI43sUimoA2KYb-nsLPzz7kWgmf-p3YuPdok90EU1QNpW4hn5AihJvGV21_-xw=@protonmail.com>
In-Reply-To: <CAD5xwhgXE9sB-hdzz_Bgz6iEA-M5-Yu2VOn1qRzkaq+DdVsgmw@mail.gmail.com>
References: <CAD5xwhgXE9sB-hdzz_Bgz6iEA-M5-Yu2VOn1qRzkaq+DdVsgmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX,
	Turing Completeness, and other considerations
Precedence: list

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 l=
ike 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 t=
he 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, n=
o? Or would have made the opcode for it as a part of taproot...
>
> But recall that the annex is committed=C2=A0to by=C2=A0the signature.
>
> So it's only a matter of time till we see some sort of Cat and Schnorr Tr=
icks III the Annex Edition that lets you use G cleverly to get the annex on=
to the stack again, and then it's like we had OP_ANNEX all along, or withou=
t 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 exe=
cution, then it does *not* have to be covered by any signature.
It would then be third-party malleable, but suppose we have a "valid" trans=
action on the mempool where the Annex weight is the minimum necessary:

* If a malleated transaction has a too-low Annex, then the malleated transa=
ction fails validation and the current transaction stays in the mempool.
* 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.

Regards,
ZmnSCPxj