public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations
Date: Sun, 6 Mar 2022 13:55:53 +0100	[thread overview]
Message-ID: <CALxbBHWztmDGraRoJEzE2r8fJgSRh_0RBGiwKWmYaE92QEDzig@mail.gmail.com> (raw)
In-Reply-To: <RDWPxsOJbtO-irPtE3xbDy-jw58ApOT2LwumhVxGXC1NgkI43sUimoA2KYb-nsLPzz7kWgmf-p3YuPdok90EU1QNpW4hn5AihJvGV21_-xw=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3057 bytes --]

  reply	other threads:[~2022-03-06 12:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 23:21 [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations Jeremy Rubin
2022-03-04 23:33 ` ZmnSCPxj
2022-03-06 12:55   ` Christian Decker [this message]
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=CALxbBHWztmDGraRoJEzE2r8fJgSRh_0RBGiwKWmYaE92QEDzig@mail.gmail.com \
    --to=decker.christian@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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