Delivery-date: Mon, 24 Mar 2025 15:00:58 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 202.12.124.155 as permitted sender) client-ip=202.12.124.155;
Feedback-ID: i525146e8:Fastmail
Date: Mon, 24 Mar 2025 16:17:46 +0000
From: Peter Todd <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Standard Unstructured Annex
Message-ID: <Z-GFqu7bfDGdLSa-@petertodd.org>
References: <Z9tg-NbTNnYciSOh@petertodd.org>
 <d906eece-2edb-428c-8d67-3836d52f4897n@googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="oK+OhC40TMpcmp+u"
Content-Disposition: inline
In-Reply-To: <d906eece-2edb-428c-8d67-3836d52f4897n@googlegroups.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--oK+OhC40TMpcmp+u
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline


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.

--oK+OhC40TMpcmp+u
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmfhhacACgkQLly11TVR
LzfO8RAAu9QlkPzFp/M5qDaWouTY8ybXJ7BYdE37ZBRfmP297pwySqWOAT9iwxYU
a0C4fW4vm0pLB7UeAF0HumHvVpJepVxqfUMXcYucbgnCKQN5kijAO9A4UQ1HHkMl
VDgwTJ8i9V1d8b4xms1aZrEWbi+xIE76DtYQlZObOKnbMLNeEWgNE57vJEo8yM3q
3DWnaPlTK8Zlo11VNI9KiuBF/8ASBWR3eoE25SBgoxbG3BGzAbvjqf1fZqM7wq0Y
qssPe92000MZB/JKyrcoMiiyKLGDrQM3MVQwUAZPs/YhMLTZsY77o1lmXw53c5cz
Fkdxbf3aOVZGPizuaYT0NDVC4OkZfL7OC2N85JdyMM/XDvqo0aGqD/uGmSLIijyF
HiDV+uv/tbITrIaW72aNPodjrUWHdU6XmQCMy5tUaqcY6qSdBT7qm3k9AJcGGe2N
SNVtMgepN9yWnFWx/b/Hwt6qrCgXgXMdIN1qiM3pV49iTLIfA+Dt5jOEePctGEPp
Qvblz/24fY/JYy1fTzbbyobEx6YNlJqc1qMfOARssQrx4BnHqTExnwR/CHjqD6Az
ZsjLzFGAnkewL2Cq2wzwooSV4wWxVzbTtz7oKGsXPCWErUukU37K/CfeUOl5Wj5A
kYIgiqGYSEjNSH7APdz9Hm02Ef2kB3I9V+tlfQWTkcPS4nLTpT4=
=UvOn
-----END PGP SIGNATURE-----

--oK+OhC40TMpcmp+u--