Delivery-date: Sun, 23 Mar 2025 18:30:17 -0700
Sender: bitcoindev@googlegroups.com
Date: Thu, 20 Mar 2025 15:47:16 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <d906eece-2edb-428c-8d67-3836d52f4897n@googlegroups.com>
In-Reply-To: <Z9tg-NbTNnYciSOh@petertodd.org>
References: <Z9tg-NbTNnYciSOh@petertodd.org>
Subject: [bitcoindev] Re: Standard Unstructured Annex
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_19968_1216546541.1742510836180"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_19968_1216546541.1742510836180
Content-Type: multipart/alternative; 
	boundary="----=_Part_19969_338050350.1742510836180"

------=_Part_19969_338050350.1742510836180
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =C3=A0 01:02:10 UTC, Peter Todd a =C3=A9crit :

> I'm working on adding support for the taproot annex to Libre Relay:
>
>
> https://github.com/petertodd/bitcoin/commit/04c8e449a34e74e048bf5751d1359=
2a22763ff7e
>
> I'm basing this on Joost Jager's pull-req:=20
> 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:
>
>
> 010000000001011a559447098aaa14dec0c62ea55f43f9ce6bda07d1759f11b634334ab9d=
a939b0000000000ffffffff010000000000000000076a05616e6e657802406840b6fa27a00b=
a001cc92797ce4f3ab7b7a32c21d1fce49e893b42e506bd92e8db187966a84ef799915cf671=
334cc59779915b192bfb66b2afcf384bb61d0f422500049276d20616e20616e6e6578212041=
726520796f7520616e20616e6e65783f0000000000
>
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
d906eece-2edb-428c-8d67-3836d52f4897n%40googlegroups.com.

------=_Part_19969_338050350.1742510836180
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,<br /><br />See also that can be relevant for taproot annex suppor=
t:<br />https://github.com/bitcoin/bips/pull/1381<br /><br />&gt; 1) All no=
n-empty annexes start with the byte 0x00, to distinguish them<br />&gt; fro=
m consensus-relevant annexes. This ensures that any use of the<br />&gt; an=
nex will not conflict with future soft-forks that may assign<br />&gt; mean=
ing to the annex.<br /><br />So IIUC, it would be 1-byte: 0x00 | &lt;random=
_data payload&gt;.<br /><br />&gt; 2) All inputs have an annex. This ensure=
s that use of the annex is<br />&gt; opt-in, preventing transaction pinning=
 attacks in multi-party<br />&gt; protocols. This requirement may be relaxe=
d in the future, eg to allow<br />&gt; spends of keyless outputs, and/or if=
 RBF for witness-only<br />&gt; replacements is implemented.<br /><br />I t=
hink it's good to start with all inputs have an annex. It avoids<br />the k=
ind of issue, like what if the annex size is inflated to downgrade<br />the=
 feerate of the multi-party transaction (e.g to have a coinjoin<br />stucki=
ng in network mempools).<br /><br />One thing that might be missed, without=
 having looked to the code, is<br />potentially a policy transaction-relay =
rule to limit the max size of the<br />annex, to avoid the same concern tha=
n above. There shouldn't be max<br />limit for now, as normally the annex i=
s not standard at all as a taproot<br />data field.<br /><br />Best,<br />A=
ntoine<br />OTS hash: 5b620c444896f05d05fe00542a4ac04c44f21684<br /><div cl=
ass=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le jeudi 20 mars=
 2025 =C3=A0 01:02:10 UTC, Peter Todd a =C3=A9crit=C2=A0:<br/></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;">I&#39;m working on adding supp=
ort for the taproot annex to Libre Relay:
<br>
<br><a href=3D"https://github.com/petertodd/bitcoin/commit/04c8e449a34e74e0=
48bf5751d13592a22763ff7e" target=3D"_blank" rel=3D"nofollow" data-saferedir=
ecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/pet=
ertodd/bitcoin/commit/04c8e449a34e74e048bf5751d13592a22763ff7e&amp;source=
=3Dgmail&amp;ust=3D1742597172176000&amp;usg=3DAOvVaw1ZApO8er4UoxBgvjqHNCnv"=
>https://github.com/petertodd/bitcoin/commit/04c8e449a34e74e048bf5751d13592=
a22763ff7e</a>
<br>
<br>I&#39;m basing this on Joost Jager&#39;s pull-req: <a href=3D"https://g=
ithub.com/bitcoin/bitcoin/pull/27926" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://gi=
thub.com/bitcoin/bitcoin/pull/27926&amp;source=3Dgmail&amp;ust=3D1742597172=
176000&amp;usg=3DAOvVaw3NBOE7rT47DCctsmiAmKxf">https://github.com/bitcoin/b=
itcoin/pull/27926</a>
<br>
<br>Specifically, transactions containing taproot annexes will be standard
<br>if:
<br>
<br>1) All non-empty annexes start with the byte 0x00, to distinguish them
<br>   from consensus-relevant annexes. This ensures that any use of the
<br>   annex will not conflict with future soft-forks that may assign
<br>   meaning to the annex.
<br>
<br>2) All inputs have an annex. This ensures that use of the annex is
<br>   opt-in, preventing transaction pinning attacks in multi-party
<br>   protocols. This requirement may be relaxed in the future, eg to allo=
w
<br>   spends of keyless outputs, and/or if RBF for witness-only
<br>   replacements is implemented.
<br>
<br>An example of a transaction meeting these requirements is:
<br>
<br>010000000001011a559447098aaa14dec0c62ea55f43f9ce6bda07d1759f11b634334ab=
9da939b0000000000ffffffff010000000000000000076a05616e6e657802406840b6fa27a0=
0ba001cc92797ce4f3ab7b7a32c21d1fce49e893b42e506bd92e8db187966a84ef799915cf6=
71334cc59779915b192bfb66b2afcf384bb61d0f422500049276d20616e20616e6e65782120=
41726520796f7520616e20616e6e65783f0000000000
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1742597172176000&amp;usg=3DAOvVaw3=
NIc9qw2c6r3kNa0tlsqvu">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1742597172176000&amp;usg=3DAOvVaw1J8LUZ-r9Edu=
HgzAIAhnP3">petertodd.org</a>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/d906eece-2edb-428c-8d67-3836d52f4897n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/d906eece-2edb-428c-8d67-3836d52f4897n%40googlegroups.com</a>.<br />

------=_Part_19969_338050350.1742510836180--

------=_Part_19968_1216546541.1742510836180--