Subject: Re: [bitcoindev] Standard Unstructured Annex

From: "'Russell O'Connor' via Bitcoin Development Mailing List" <[email-masked]>
Date: Mon, 28 Apr 2025 12:25:08 -0400

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 <[email-masked]>
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 <[email-masked]> 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 [email-masked].
>> 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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAMZUoKmu8NeFzjU1vuU6AmxZ0T7VnZ-s7rqsHaiZjmZrL3v5DQ%40mail.gmail.com.