Author: Antoine Riard 2023-06-18 20:32:12+00:00
Published on: 2023-06-18T20:32:12+00:00
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. Failure to upgrade Lightning nodes accordingly would disrupt the propagation of their `option_taproot` channel transactions.Secondly, there is another approach suggested to limit the maximum size or weight of the witness/transaction as a TLV (Type-Length-Value) record itself. This approach is discussed in a branch located at https://github.com/bitcoin-inquisition/bitcoin/pull/28. It also implements the "only allow tlv record 0" with the TLV format from BIP #1381. This approach aims to protect opt-in users.Joost Jager proposes a set of policies that enable annex-vaults while considering existing work and future extensibility. These policies include opting into an annex for every input, using the Tlv format as defined in BIP #1381, allowing only unstructured data in tlv record 0, and limiting the maximum size of the value to 256 bytes. However, it is pointed out that the previously proposed limit of 126 bytes may not be sufficient for certain vault scenarios, where multiple presigned transactions and additional parameters need to be stored.The discussion seeks to address any remaining practical objections to making the annex standard under the conditions outlined above.
Updated on: 2023-07-14T02:43:09.714163+00:00