From: "'Russell O'Connor' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Standard Unstructured Annex
Date: Mon, 28 Apr 2025 12:25:08 -0400 [thread overview]
Message-ID: <CAMZUoKmu8NeFzjU1vuU6AmxZ0T7VnZ-s7rqsHaiZjmZrL3v5DQ@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKkczgSZiJAjicBLTVhA88egqpLF8y+zN3LmZ14yAdRY1Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4864 bytes --]
next prev parent reply other threads:[~2025-04-29 0:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 0:27 Peter Todd
2025-03-20 22:47 ` [bitcoindev] " Antoine Riard
2025-03-24 16:17 ` Peter Todd
2025-04-09 22:55 ` Antoine Riard
2025-04-28 16:13 ` [bitcoindev] " 'Russell O'Connor' via Bitcoin Development Mailing List
2025-04-28 16:25 ` 'Russell O'Connor' via Bitcoin Development Mailing List [this message]
2025-04-29 2:59 ` Peter Todd
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=CAMZUoKmu8NeFzjU1vuU6AmxZ0T7VnZ-s7rqsHaiZjmZrL3v5DQ@mail.gmail.com \
--to=bitcoindev@googlegroups.com \
--cc=pete@petertodd$(echo .)org \
--cc=roconnor@blockstream$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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