* [bitcoindev] Standard Unstructured Annex
@ 2025-03-20 0:27 Peter Todd
2025-03-20 22:47 ` [bitcoindev] " Antoine Riard
0 siblings, 1 reply; 3+ messages in thread
From: Peter Todd @ 2025-03-20 0:27 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoindev] Re: Standard Unstructured Annex
2025-03-20 0:27 [bitcoindev] Standard Unstructured Annex Peter Todd
@ 2025-03-20 22:47 ` Antoine Riard
2025-03-24 16:17 ` Peter Todd
0 siblings, 1 reply; 3+ messages in thread
From: Antoine Riard @ 2025-03-20 22:47 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3148 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 4958 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoindev] Re: Standard Unstructured Annex
2025-03-20 22:47 ` [bitcoindev] " Antoine Riard
@ 2025-03-24 16:17 ` Peter Todd
0 siblings, 0 replies; 3+ messages in thread
From: Peter Todd @ 2025-03-24 16:17 UTC (permalink / raw)
To: Antoine Riard; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]
On Thu, Mar 20, 2025 at 03:47:16PM -0700, Antoine Riard wrote:
> Hi Peter,
>
> See also that can be relevant for taproot annex support:
> https://github.com/bitcoin/bips/pull/1381
Thanks.
> > 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>.
Correct.
When annex data finally does get a consensus meaning any encoding scheme
starting with a non-zero byte will be compatible. Most likely we'll get
some tag-length-value encoding scheme.
Applications already using annexes who want to also take advantage of
new consensus features will of course have to upgrade their encoding
schemes to match. But I think that's fine.
> > 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).
Glad to hear you agree.
> 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.
Libre Relay has no limit on OP_Return output size; I'm not going to
artificially limit annex usage either. The requirement to opt-in to
annex usage should be sufficient.
There is a possibility of a multi-party, annex-using, protocol where
someone does a pinning attack by re-signing their transaction with a
bigger annex. But witness-RBF in combination with replace-by-fee-rate
will fix this, so I'm not concerned. No such protocols actually exist
yet anyway, so we can figure that out later.
--
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/Z-GFqu7bfDGdLSa-%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-03-24 22:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-03-20 0:27 [bitcoindev] Standard Unstructured Annex Peter Todd
2025-03-20 22:47 ` [bitcoindev] " Antoine Riard
2025-03-24 16:17 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox