Author: Greg Sanders 2023-06-03 01:14:40
Published on: 2023-06-03T01:14:40+00:00
In a discussion on the bitcoin-dev mailing list, Greg Sanders shared his draft for ln-symmetry and cited the recent discussions around the annexcarrier option in Bitcoin. The annex field is a new feature introduced by Taproot that allows developers to include additional data in the SegWit witness of a transaction. However, BIP341/342 signature hashes do not cover other inputs' annex fields, which means that in a coinjoin scenario, a malicious party can make the signed transaction into a maximum-sized transaction package, causing griefing. One solution suggested was to limit the annex usage to 126 bytes or require all inputs to commit to an annex to be relay-standard. The logs related to this issue are available in a GitHub link provided. There was also a discussion on possible BIP118 modifications to mitigate this in tapscript-spending circumstances. Joost Jager pointed out the benefits of making the annex available in a non-structured form, and David A. Harding asked about the features and benefits available today. Sanders wants to use annex data with LN-Symmetry, but that's dependent on a soft fork of SIGHASH_ANYPREVOUT. It was suggested that putting arbitrary data into a witness without having to commit to it beforehand would only increase the efficiency of witness stuffing like ordinal inscriptions by only 0.4%.
Updated on: 2023-06-16T18:46:11.963833+00:00