Standard Unstructured Annex

A notable shift is anticipated towards adopting tag-length-value (TLV) encoding for annex data, which implies that any encoding commencing with a non-zero byte could become compatible once a consensus is reached. This evolution necessitates applications currently deploying annexes to update their encoding schemes to align with forthcoming consensus features, symbolizing a stride towards standardization and improved functionality. Furthermore, the Libre Relay's stance on the OP_Return output size, which imposes no limitations, mirrors a broader hesitation to unnecessarily restrict annex usage. Instead, an opt-in mechanism is considered adequate to regulate participation, acknowledging potential risks such as pinning attacks in multi-party protocols. These risks involve re-signing transactions with enlarged annexes, but a proposed solution incorporates witness-RBF with replace-by-fee-rate mechanisms as a countermeasure. The absence of protocols vulnerable to these attacks provides room for developing future solutions as necessary. Insights into these discussions can be gained through Peter Todd's work.

Antoine brings up a proposal regarding taproot annex support, suggesting the initiation of all inputs with an annex that combines a zero byte (0x00) with a random data payload. This method aims to address concerns related to annex size inflation potentially reducing multi-party transaction fee rates and causing network congestion by making coinjoin transactions difficult to process. Additionally, the lack of a policy capping the maximum annex size could exacerbate these issues since the annex, being a non-standard taproot data field, does not currently have a size limit. This observation highlights the need for further examination and possibly the implementation of transaction-relay policies to enforce a cap on annex size, thereby mitigating associated risks.

The integration of taproot annex support into Libre Relay, influenced by existing proposals and commits on GitHub, sets forth conditions for transactions containing taproot annexes to be deemed standard. These include the requirement for all non-empty annexes to start with byte 0x00, distinguishing them from future consensus-relevant annexes and preventing conflicts with subsequent soft-forks. Furthermore, it stipulates that all inputs within a transaction must feature an annex, positioning annex use as an opt-in feature to deter transaction pinning attacks within multi-party protocols. Although this criterion may be adjusted in the future to accommodate changes such as the spends of keyless outputs or the introduction of Replace-by-Fee (RBF) for witness-only replacements, it currently demonstrates the application of these guidelines in practice. This initiative is reflective of ongoing dialogues and efforts within the Bitcoin Development Mailing List to innovate and modify Bitcoin's protocol and its associated projects. Antoine’s involvement and contributions to these discussions are facilitated through his subscription to the mailing list, with additional contact and information available through Peter Todd's website.