From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Jeremy Rubin <jeremy.l.rubin@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations
Date: Fri, 04 Mar 2022 23:33:10 +0000 [thread overview]
Message-ID: <RDWPxsOJbtO-irPtE3xbDy-jw58ApOT2LwumhVxGXC1NgkI43sUimoA2KYb-nsLPzz7kWgmf-p3YuPdok90EU1QNpW4hn5AihJvGV21_-xw=@protonmail.com> (raw)
In-Reply-To: <CAD5xwhgXE9sB-hdzz_Bgz6iEA-M5-Yu2VOn1qRzkaq+DdVsgmw@mail.gmail.com>
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
next prev parent reply other threads:[~2022-03-04 23:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-04 23:21 Jeremy Rubin
2022-03-04 23:33 ` ZmnSCPxj [this message]
2022-03-06 12:55 ` Christian Decker
2022-03-05 5:59 ` Anthony Towns
2022-03-05 12:20 ` Jeremy Rubin
2022-03-07 8:08 ` Anthony Towns
2022-03-06 13:12 ` Christian Decker
2022-03-06 13:21 ` Jeremy Rubin
2022-03-07 0:59 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='RDWPxsOJbtO-irPtE3xbDy-jw58ApOT2LwumhVxGXC1NgkI43sUimoA2KYb-nsLPzz7kWgmf-p3YuPdok90EU1QNpW4hn5AihJvGV21_-xw=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jeremy.l.rubin@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox