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

The email from Antoine elaborates on the complexities of handling HTLC (Hashed TimeLock Contract) outputs within a blockchain context that utilizes the Eltoo update mechanism, which assumes no revoked state can be broadcast. Antoine's description centers around a new covenant mechanism designed to aggregate or collapse all HTLC outputs into one or two outputs—specifically categorized as offered and received. This aggregation aims to streamline transaction processes but introduces potential security vulnerabilities.

Antoine points out that an aggregated HTLC output for offered payouts could include multiple individual "payouts" where each payout is subjected to max standard transaction relay limits among other constraints. The mechanics of using these aggregated outputs require a party to present a combination of preimages and signatures to satisfy the script's locking conditions. However, this setup allows the possibility of only partially revealing preimages, thereby not fully disclosing the details of the transaction to the counterparty.

A significant concern raised relates to what Antoine terms "replacement cycling attacks." In such scenarios, a malicious actor could exploit the aggregation by selectively revealing preimages and spending small portions of an HTLC payout while incurring high transaction fees. This strategy would effectively push other legitimate transactions (like Alice's timeout transactions) out of network mempools due to concurrent spending attempts. A detailed example describes how Bob could manipulate the system to eventually double-spend a larger HTLC payout after repeatedly cycling through smaller payouts, thereby covering his tracks with miner fees generated from these high-fee low-value transactions.

Furthermore, Antoine suggests that mitigating such attacks might involve more than just setting adequate fees; it could also require adjusting the sliding delay of the HTLC timelocks based on block feerate to prevent attackers from benefiting from mempool congestion. Additionally, he touches on the challenges in a Taproot-enhanced blockchain environment, particularly the increased witness size in scenarios of non-cooperative closures. He proposes the introduction of an accumulator at the script level to efficiently handle partial set membership checks, noting that issues like exponential blowup also pose significant risks during mass non-coordinated withdrawals from a payment pool.

For further details on this discussion, refer to the conversation documented on the Linux Foundation's mailing list, accessible via this link.