Hi Joost,

Thanks for detailing why a '0' as free-form, without any additional constraints offers valuable engineering properties as of today.

From a taproot annex design perspective, I think this could be very valuable if you have a list of unstructured data use-cases you're thinking about ? As raised on the BIP proposal, those unstructured data use-cases could use annex tags with the benefit to combine multiple "types" of unstructured data in a single annex payload. As you're raising smaller bits of unstructured data might not afford the overhead though my answer with this observation would be to move this traffic towards some L2 systems ? In my mind, the default of adding a version byte for the usage of unstructured data comes with the downside of having future consensus enabled use-cases encumbering by the extended witness economic cost.

About the annex payload extension attack described by Greg. If my understanding of this transaction-relay jamming griefing issue is correct, we can have an annex tag in the future where the signer is committing to the total weight of the transaction, or even the max per-input annex size ? This should prevent a coinjoin or aggregated commitment transaction counterparty to inflate its annex space to downgrade the overall transaction feerate, I guess. And I think this could benefit unstructured data use-cases too.

Best,
Antoine

Le ven. 2 juin 2023 à 22:18, Joost Jager via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a écrit :
Hi,

As it stands, the taproot annex is consensus valid but non-standard. The conversations around standardization seem to be leaning towards the adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt that this approach has considerable potential. However, settling on an exact format may require a significant amount of time.

In the interim, the benefits of making the annex available in a non-structured form are both evident and immediate. By allowing developers to utilize the taproot annex without delay, we can take advantage of its features today, without the need to wait for the finalization of a more lengthy standardization process.

With this in view, I am proposing that we define any annex that begins with '0' as free-form, without any additional constraints. This strategy offers several distinct benefits:

Immediate utilization: This opens the door for developers to make use of the taproot annex for a variety of applications straight away, thus eliminating the need to wait for the implementation of TLV or any other structured format.

Future flexibility: Assigning '0'-beginning annexes as free-form keeps our options open for future developments and structure improvements. As we forge ahead in determining the best way to standardize the annex, this strategy ensures we do not limit ourselves by setting its structure in stone prematurely.

Chainspace efficiency: Non-structured data may require fewer bytes compared to a probable TLV format, which would necessitate the encoding of length even when there's only a single field.

In conclusion, adopting this approach will immediately broaden the utilization scope of the taproot annex while preserving the possibility of transitioning to a more structured format in the future. I believe this is a pragmatic and efficient route, one that can yield substantial benefits in both the short and long term.

Joost

[1] https://github.com/bitcoin/bips/pull/1381
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev