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 ?
The annex's list of unstructured data use-cases includes existing data storage uses that utilize OP_RETURN or inscriptions. Consider ordinals, timestamps, and any other data already stored on the chain. These applications would immediately benefit from the annex's improved space efficiency.
However, the primary advantage I see in the annex is that its data isn't included in the calculation of the txid or a potential parent commit transaction's txid (for inscriptions). I've explained this at [1]. This feature makes the annex a powerful tool for applications that would ideally use covenants.
The most critical application in this category, for me, involves time-locked vaults. Given the positive reception to proposals such as OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probably a bit further out, but pre-signed transactions signed using an ephemeral key can fill the gap and improve the safeguarding of Bitcoin in the short term.
Backing up the ephemeral signatures of the pre-signed transactions on the blockchain itself is an excellent way to ensure that the vault can always be 'opened'. However, without the annex, this is not as safe as it could be. Due to the described circular reference problem, the vault creation and signature backup can't be executed in one atomic operation. For example, you can store the backup in a child commit/reveal transaction set, but the vault itself can be confirmed independently and the backup may never confirm. If you create a vault and lose the ephemeral signatures, the funds will be lost.
This use case for the annex has been labeled 'speculative' elsewhere. To me, every use case appears speculative at this point because the annex isn't available. However, if you believe that time-locked vaults are important for Bitcoin and also acknowledge that soft forks, such as the one required for OP_VAULT, aren't easy to implement, I'd argue that the intermediate solution described above is very relevant.
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.
When it comes to the trade-offs associated with various encodings, I fully acknowledge their existence. The primary motivation behind my proposal to adopt a simple approach to the Taproot annex is to avoid a potentially long standardization process. While I am not entirely familiar with the decision-making process of Bitcoin Core, my experience with other projects suggests that simpler changes often encounter less resistance and can be implemented more swiftly. Perhaps I am being overly cautious here, though.
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.
Regarding the potential payload extension attack, I believe that the changes proposed in the [3] to allow tx replacement by smaller witness would provide a viable solution?
Joost