Hi Peter,

See also that can be relevant for taproot annex support:
https://github.com/bitcoin/bips/pull/1381

> 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.

So IIUC, it would be 1-byte: 0x00 | <random_data payload>.

> 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.

I think it's good to start with all inputs have an annex. It avoids
the kind of issue, like what if the annex size is inflated to downgrade
the feerate of the multi-party transaction (e.g to have a coinjoin
stucking in network mempools).

One thing that might be missed, without having looked to the code, is
potentially a policy transaction-relay rule to limit the max size of the
annex, to avoid the same concern than above. There shouldn't be max
limit for now, as normally the annex is not standard at all as a taproot
data field.

Best,
Antoine
OTS hash: 5b620c444896f05d05fe00542a4ac04c44f21684
Le jeudi 20 mars 2025 à 01:02:10 UTC, Peter Todd a écrit :

> 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/d906eece-2edb-428c-8d67-3836d52f4897n%40googlegroups.com.