HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants)

The discussion opens with an examination of a transaction recycling attack, a vulnerability enabled by recent changes to HTLC second-level transactions in anchor channel types. This alteration allows for the addition of inputs to increase fees without violating the signature, contrasting with legacy channel types where all fees had to be derived from the HTLC outputs themselves and agreed upon by channel counterparts during signing. This difference introduces a risk in legacy channels where if the holder's commitment transaction confirms first, the second-stage HTLC claim transaction becomes fully malleable by the counterparty. The potential for a replacement cycling attack persists even as the network transitions towards a package-relay system.

The email also addresses the benefits of HTLC output aggregation, notably the reduced need for fee-bumping reserves due to common fields in second-stage HTLC transactions which might allow for shared usage. However, this approach is critiqued for leaving a level of malleability that could potentially lead to the loss of all HTLC value promised to the counterparty via miner's fees. A proposed solution to enhance security involves segregating HTLC claims into two separate outputs with complete replication of the HTLC lockscripts, allowing a covenant to either accept or reject aggregated claims based on satisfying witness and chain state conditions related to time locks.

Further, the correspondence touches upon systemic limitations imposed by protocol-defined maxima, such as the 483 limit impacting the payment throughput of the Lightning Network (LN). It suggests that aggregating claims could dynamically adjust what constitutes a tangible and trust-minimized HTLC payment. Yet, challenges remain, such as achieving off-chain consensus on feerate thresholds for sliding windows that manage claim periods within HTLC pathways. Potential advancements in PTLC mechanisms are considered, with the idea of generating an aggregate curve point for sub-combinations of scalar values, thereby maintaining near-constant size for offered HTLCs and enhancing scalability without compromising security.

In the broader context of layer-two solutions and smart contracts, the email highlights ongoing concerns regarding the design and implementation of complex covenants, particularly those that might inadvertently support malicious activities within Bitcoin’s ecosystem. This includes a call for an efficiency simulation framework to better understand the performance trade-offs between different covenant constructions, referencing public discussions and debates that have historically surfaced around these topics, such as those during the CTV drama and payment pool discussions.

For further reading and references on these issues, consider reviewing the detailed discussions at GitHub - Lightning/Bolts, GitHub - Ariard/Bitcoin, and insights into HTLC and LN scalability at FC22 Preproceedings and BitMEX Blog.