Resources

• Mailing List: Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
• Research PDF: Replacement Cycling Attacks on the Lightning Network by Antoine Riard
• Blog Post: How Does a Lightning Replacement Cycling Attack Work - Illustrated Primer by @mononaut on X
• Audio Discussion: @niftynei explains the attack on X Spaces
• Podcast: Rabbit Hole Recap #275: Critical Flaw on the Lightning Network?
• Article: Postmortem on the Lightning Replacement Cycling Attack

The Basics

• Bitcoin Mempool: Think of the mempool as a waiting room for Bitcoin transactions. Before a transaction is added to a block and confirmed, it waits here. The mempool has limited space, and transactions compete to get in, primarily through fees.
• Replace-by-Fee (RBF): This rule in Bitcoin allows a user to replace their transaction in the mempool with another that has a higher fee. It's like raising your bid at an auction.

The Attack in Detail

1. Two-Channel Setup: To initiate the attack, the attacker needs to open two channels with the victim and then route a payment through them. It's not an easy task, but it's a foundational step.
2. Playing the Replacement Game: Using RBF, the attacker continuously replaces transactions in the mempool, ensuring the target's transactions never confirm.
3. Collusion Aspect: Alice and Carol, two parties, could collude against Bob (the victim). For instance, while Bob is routing a lightning payment from Alice to Carol, the attackers broadcast two low-fee transactions, the "cycle parent" and "cycle child", which are seemingly unrelated to the lightning channel. This forms the basis for a more complex attack.
4. The Cycle: As soon as Bob's htlc-timeout transaction appears in the mempool, the attackers use an "htlc-preimage" transaction that spends both the HTLC output and an output from the cycle parent. This effectively replaces Bob's transaction. The attackers then initiate a replacement cycle ensuring Bob's transactions never stay in the mempool. If executed successfully, this can lead to Bob losing the entire value of the payment.
5. Outcome: The target's transactions either get delayed or never confirm. In the Lightning Network context, this can cause fund loss.

Concerns for the Lightning Network

Solutions and Mitigations

• Aggressive Rebroadcasting: By continuously broadcasting their transactions, users can escalate the cost for the attacker. This makes the attack more expensive and less appealing.
• Local Mempool Monitoring: By actively tracking their transactions in the mempool, users can detect suspicious activities and take preventive measures.
• Adjusting Time Parameters in LN: Fine-tuning certain time-related settings in the LN can reduce susceptibility to these types of attacks.
• Presigned Fee Multiplier for HTLC Spends: One proposed solution is to modify the HTLC scripts so both parties can only expend the HTLC through presigned second-stage transactions with a fixed SIGHASH_ALL. This stops the attacker from adding inputs to their presigned transaction, effectively thwarting replacement cycling attacks. To cater to the needs of fee bumping, a sequence of presigned transactions with incrementing fees can be established. This can employ a multiplier system starting with smaller multipliers and transitioning to larger ones as needed.
• Fee Ranges with Presigned Transactions: By pre-signing a series of replacement transactions that increment the fee at each step using a set multiplier, users can ensure efficient fee management. For example, beginning with smaller multipliers (1.1, 1.2, 1.4) and then transitioning to more significant increments (1.8, 2.6, etc.) can ensure minor bumps for small adjustments and major bumps when aggressive strategies are necessary.
• Commitment Transactions with HTLC Removals: As fees rise, commitment transactions can be modified to exclude HTLCs, especially when an HTLC's value is less than the required mining fees.
• Deducting Fees from Different Party's Outputs: This strategy involves both parties authorizing each other to broadcast transactions with increasing fees. The additional fees can be deducted from their respective outputs, facilitated by traditional multisignature setups.

Short Term Mitigations

• Lower the HTLC Max Setting: By decreasing the maximum setting on channels that aren't fully trusted, users can minimize the potential loss due to an attack.
• Curate Nodes for Channel Opening: Users should be selective and cautious about the nodes they establish channels with, minimizing exposure to potentially malicious nodes. Be sceptical with brand new nodes opening very large channels. Here on LN+, users can assess the reputation of nodes based on the number of positive ratings they've received.
• Adjust your CLTV Delta Setting: If your node's CLTV delta setting is below 144, consider increasing it. This gives transactions more time to be confirmed on the blockchain, adding an extra layer of security.
• Stay Updated with Software Mitigations: Always keep an eye out for software updates that include security improvements. For instance, LND 0.16.1, which was released six months ago, already incorporated mitigations by elevating the default CLTV delta delay.

Conclusion