delvingbitcoin

[WITHDRAWN] Alternate script design for LNHANCE-Symmetry

[WITHDRAWN] Alternate script design for LNHANCE-Symmetry

Original Postby reardencode

Posted on: April 27, 2024 14:14 UTC

The discussion revolves around the innovative approaches to Lightning Symmetry channel scripts, particularly focusing on their design when used with LNHANCE in contrast to APO.

It highlights the script structures for both LNHANCE and APO variants, detailing their specific components like the musig2 for LNHANCE versus musig for APO and the different approaches to tapleaves and OP_IF constructions. The essence of these constructions is how they manage settlement transactions and updates, with LNHANCE leveraging the CTV hash as an internal key for taproot outputs, which streamlines the update process by making tapscripts consistent across updates. This method allows for storage and spending efficiency, requiring minimal data storage for either party involved.

Greg's thread provides essential background information, highlighting the technical nuances of each approach. For example, the APO-Symmetry design utilizes a taproot annex to store the hash of the settlement transaction, facilitating the recovery of the necessary taproot sibling hash for spending Alice's update if Bob has a later update. In contrast, LNHANCE-Symmetry's use of the settlement transaction's CTV hash as an internal key offers a unique advantage by ensuring tapscripts remain identical from one update to the next, enhancing efficiency and reducing the complexity involved in managing updates.

Witness sizes for both APO and LNHANCE Symmetry variants are compared, showcasing the differences in weight units (WU) across initial updates, subsequent updates, and settlements. The comparison demonstrates that LNHANCE-Symmetry, especially in its OP_IF variant, tends to favor non-challenged closes significantly more than APO-Symmetry, leading to substantial weight savings in certain scenarios. However, it is noted that these savings are somewhat reduced when including the CTV hash in the update witness stack, revealing the nuanced trade-offs between the two approaches.

In conclusion, the choice between APO-Symmetry and LNHANCE-Symmetry for building production Lightning Symmetry channels may depend on the value placed on minimizing the weight of unchallenged force closes versus the cost and complexity of handling challenges when they arise. The detailed analysis underscores the potential benefits of integrating the settlement hash into the taproot internal key within LNHANCE-Symmetry channels, suggesting significant implications for the efficiency and practicality of future Lightning Network enhancements.