Thursday, July 18, 2024

Postmortem On The Lightning Replacement Cycling Attack

There has been a recent buzz surrounding the Lightning vulnerability that was disclosed by Antoine Riard. Many people are making doom and gloom claims about the state of Lightning, but this is far from the truth. The issue lies in the lack of understanding about how the vulnerability actually works, and how it overlaps with other known problems on the Lightning Network that already have solutions. In order to fully comprehend the vulnerability, one must first understand the timelocks involved in refunding a failed payment. This article aims to delve into the details of the Lightning Replacement Cycling Attack, discussing the complexities and implications of this targeted and manipulative game. While this is a legitimate issue, it is by no means an insurmountable problem.

Understanding the Vulnerability

The recently disclosed Lightning vulnerability has caused a lot of commotion and raised concerns about the stability of the Lightning Network. However, it is crucial to understand the vulnerability and its relationship with other known issues on the network. Firstly, let’s delve into how this vulnerability works. When a payment is routed through the Lightning Network, the timelocks for refunding a failed payment play a significant role. Starting from the hop closest to the receiver, the timelocks progressively increase by one as the payment moves back towards the sender. This ensures that if an issue arises and the preimage fails to reach the sender, the hop where it stops has enough time to enforce it on-chain and include the preimage. Otherwise, someone in the middle of the route could claim the funds, leaving the original receiver at a loss.

The Replacement Cycling Attack is a complex method to achieve this undesired outcome, where the outgoing hop claims the funds with a success transaction, and the incoming hop claims the funds through the refund transaction. To execute this attack, the victim’s node must be manipulated, and the preimage must be withheld until after the refund transaction’s timelock expires. This requires precise targeting and control over the victim’s mempool.

Transaction Structure Involved

To better understand the attack, let’s examine the transaction structure involved. The commitment transaction represents the state of the Lightning channel and includes outputs for each party involved, as well as outputs for HTLCs (Hash Time-Locked Contracts) being routed. The concern lies with these HTLC outputs, which can be spent immediately with the preimage or after the refund timelock expires.

Execution of the Attack

The attackers must fulfill certain requirements to execute the attack successfully. They need to have a channel on both sides of the victim’s node, with one side being the attacker and the other being the victim. As payment is routed through Bob, the victim, one of the attackers, Alice, refuses to send Bob the preimage needed to finalize the payment. Bob then waits until the timelock window between himself and Alice expires and proceeds to broadcast the channel’s commitment and refund transactions. Meanwhile, Alice spends the preimage transaction to claim the funds and immediately double-spends the second input in the preimage success transaction. The goal is to evict Bob’s timeout transaction from the mempool, preventing him from seeing the preimage success transaction and claiming the funds before Carol’s timeout transaction becomes valid.

To consistently execute the attack, Alice and Carol, the attackers, must repeatedly attempt to evict Bob’s timeout transaction from the mempool every time he rebroadcasts it. They continue this until the block height exceeds the validity of Carol’s timeout transaction. At this point, they can submit the success transaction on Alice’s side and the timeout transaction on Carol’s side, leaving Bob with lost funds.

Challenges and Costs

Executing this attack poses challenges for the attackers. Firstly, they must specifically target the victim’s Bitcoin Core node to ensure that the preimage success transaction does not enter their mempool. Secondly, if Alice confirms the second transaction to evict the preimage transaction, she incurs a cost. Bob can force Alice to bear increasingly higher costs by regularly rebroadcasting his timeout transaction with a higher fee. This means the attack is only economically feasible if the payment’s value outweighs the fees that Alice could potentially incur.

Mitigating the Attack

There are several ways to mitigate the Replacement Cycling Attack. One approach is for Bob to regularly rebroadcast his timeout transaction with a slight fee increase. This forces Alice to continually pay higher fees to evict the transaction. By using the SIGHASH_ALL flag for success and timeout transactions, where the signature commits to the entirety of the transaction, any alterations, such as adding the new input required for the attack, invalidate the signature. While this solution is not compatible with current Lightning channels using anchor outputs, it offers a complete resolution to the attack. Peter Todd has also proposed a new consensus feature that would address the issue, introducing a reverse timelock where the transaction becomes invalid after a certain time or block height.

Limited Impact and Future Improvements

The Replacement Cycling Attack has limited impact in the broader context of the Lightning Network. Individuals who are not routing nodes do not face serious risks from this attack. Furthermore, large nodes, which would be attractive targets, are selective in their peer selection and channel opening. They prioritize professional and efficient management of channels, making it challenging to establish multiple channels with them to execute the attack. Additionally, the network is evolving to handle various attacks and issues. This evolution includes implementing criteria and filters for payment forwarding, such as limits on payment size and quantity.

To further improve the network, the development of criteria and filters for payment forwarding should continue. Selective channel opening and peer selection will enhance security. Lastly, long-term solutions should be explored to address multiple network issues, ensuring the Lightning Network remains robust.


It is crucial to acknowledge the existence of the Replacement Cycling Attack and its ramifications. However, it is equally vital not to panic or overreact. This vulnerability overlaps with other known issues on the Lightning Network, and solutions are being proposed and implemented. The Lightning Network is not fundamentally broken, and as with any evolving technology, challenges will arise and be addressed. It is important to recognize the problem, continue working on solutions, and maintain a measured perspective on the future of the Lightning Network.