Ah nevermind, I get it now.

The contrapositive of this proposed standardness rule is that if one annex is empty, then all annexes must be empty.  Therefore if on participants signs an empty annex, then standardness would imply that all the annexes must be empty.

On Mon, Apr 28, 2025 at 12:13 PM Russell O'Connor <roconnor@blockstream.com> wrote:
Can you provide more details on how all inputs having an annex prevents transaction pinning attacks in multi-party protocols?

From my naive understanding, in multi-party protocols one party can grief by inflating the weight of their annex and broadcast their heavier / lower-fee rate version of the transaction, and having an annex in all inputs does not help this because one party can still change their own annex, resign, and broadcast their heavier transaction.

However, I'm not up to date on the latest details about full RBF and pinning attacks, so there is a good chance I'm missing something here.

On Wed, Mar 19, 2025 at 9:02 PM Peter Todd <pete@petertodd.org> wrote:
I'm working on adding support for the taproot annex to Libre Relay:

https://github.com/petertodd/bitcoin/commit/04c8e449a34e74e048bf5751d13592a22763ff7e

I'm basing this on Joost Jager's pull-req: https://github.com/bitcoin/bitcoin/pull/27926

Specifically, transactions containing taproot annexes will be standard
if:

1) All non-empty annexes start with the byte 0x00, to distinguish them
   from consensus-relevant annexes. This ensures that any use of the
   annex will not conflict with future soft-forks that may assign
   meaning to the annex.

2) All inputs have an annex. This ensures that use of the annex is
   opt-in, preventing transaction pinning attacks in multi-party
   protocols. This requirement may be relaxed in the future, eg to allow
   spends of keyless outputs, and/or if RBF for witness-only
   replacements is implemented.

An example of a transaction meeting these requirements is:

010000000001011a559447098aaa14dec0c62ea55f43f9ce6bda07d1759f11b634334ab9da939b0000000000ffffffff010000000000000000076a05616e6e657802406840b6fa27a00ba001cc92797ce4f3ab7b7a32c21d1fce49e893b42e506bd92e8db187966a84ef799915cf671334cc59779915b192bfb66b2afcf384bb61d0f422500049276d20616e20616e6e6578212041726520796f7520616e20616e6e65783f0000000000

--
https://petertodd.org 'peter'[:-1]@petertodd.org

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z9tg-NbTNnYciSOh%40petertodd.org.

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAMZUoKmu8NeFzjU1vuU6AmxZ0T7VnZ-s7rqsHaiZjmZrL3v5DQ%40mail.gmail.com.