Published on: 2023-07-04T20:18:23+00:00
In a recent email exchange, Antoine and Joost discussed the potential benefits of using the annex feature for Bitcoin's time-locked vault applications. Joost emphasized that the annex data is not included in the calculation of transaction IDs, making it a powerful tool for applications that could benefit from covenants. He specifically mentioned time-locked vaults as a critical application that could greatly benefit from the annex.Joost explained that backing up the ephemeral signatures of pre-signed transactions on the blockchain itself is an excellent way to ensure that the vault can always be accessed. However, without the annex, this process is not as safe as it could be. Due to a circular reference problem, the vault creation and signature backup cannot be executed in one atomic operation. This means that if the backup does not confirm, the funds can be lost even if the vault is confirmed.Despite being labeled as speculative, Joost argued that the use case for the annex in time-locked vaults is relevant, especially considering the difficulty of implementing soft forks like OP_VAULT. To support this use case, Joost created a simple demo application that demonstrates how coins can be spent to a special address and later moved to a predefined final destination. The demo uses the annex to store the ephemeral signature of the pre-signed transaction, ensuring that the coin cannot be lost.Joost also highlighted the importance of raising awareness about the on-chain ephemeral signature backup functionality enabled by the annex. He provided a link to his demo application on GitHub, which showcases the potential of the annex for implementing more advanced covenants, such as time-locked vaults.Overall, Joost and Antoine's discussion sheds light on the potential benefits of using the annex for time-locked vault applications and emphasizes the need for further exploration and adoption of the annex feature.In another email exchange between Antoine Riard and Joost, they discuss the concept of an opt-in annex in multi-party transactions. The purpose of this approach is to prevent surprises within multi-party transactions. If someone doesn't commit to an annex, they can be confident that no version of the transaction will appear where another signer includes a potentially large annex. This ensures that existing multi-party protocols remain unaffected.For future protocols that rely on the annex, everyone involved would need to opt-in by committing to an annex. The annex can be empty, serving only as a signal of opting in. The goal is to maintain transparency and avoid unexpected variations in transaction versions.In a separate email thread, Antoine Riard seeks clarification on the topic of opt-in annexes in relation to non-deployed and deployed protocols. Greg Sanders requests a citation for the claim that people should not build protocols meant for production on undeveloped upgrade hooks. Antoine acknowledges that ideally, premature choices should not encumber future development, but mentions that if certain use cases gain economic weight, the coordination cost of deploying a new policy may be prohibitive. In such cases, he suggests implementing sound and "firewalled" signaling and upgrading mechanisms to deploy new policy rules smoothly. Greg seeks further clarification on Antoine's mention of modifying current Taproot support on the Lightning side, specifically regarding the requirement of all P2TR spends to add an annex and commit to it in the BIP341 signature digest. Antoine explains that this would be a mandatory upgrade for Lightning nodes, as failure to do so would disrupt the propagation of `option_taproot` channel transactions. Antoine also discusses the possibility of introducing a TLV record to limit the maximum size/weight of the witness/transaction.The email conversation continues with Joost Jager proposing a restrictive policy for enabling annex-vaults while still aligning with existing work. This policy includes opt-in annexes for every input, the use of TLV format for future extensibility, only allowing unstructured data in tlv record 0 for future extensibility, and limiting the maximum size of the value to 256 bytes to protect opt-in users. Joost highlights the need for a larger limit than the current 126 bytes proposed in a previous pull request, as it would not be sufficient for certain vault configurations. He asks if there are any remaining objections to making the annex standard under these conditions.The discussion revolves around two key points. First, there is a proposal to require every input to commit to an annex, even if it is empty. This could potentially affect the existing multi-party protocols. The concern raised is whether a transaction without the minimal annex, indicated by the 0x50 tag, should be rejected. Implementing this would require modifying current Taproot support on the Lightning side, where all P2TR spends must add an annex and commit to it in the BIP341 signature digest.
Updated on: 2023-08-02T09:34:03.267700+00:00