
Unjamming the Lightning Network: A Comprehensive Solution to Channel Jamming Attacks
One of the most pressing challenges facing the Lightning Network (LN) has finally found a solution. This article delves into the intricacies of channel jamming, its impact, and a novel "hybrid" approach to mitigate this issue.
What is Channel Jamming?
Channel jamming is essentially a Denial of Service (DoS) attack targeted at Lightning channels. The primary objective of this attack is to render a Lightning channel inoperative.
How Does It Work?
To carry out this attack, a malicious actor establishes two nodes and initiates payments between them. However, the attacker deliberately withholds the preimage—the secret number that unlocks funds across the route—for each payment, causing the payment to remain "in flight."
By not releasing the secret, the attacker can let payments hang in flight until the timelock on the Hashed Timelock Contract (HTLC) expires. This is problematic because each channel can only accommodate a fixed number of in-flight payments, which is 483.
Why Only 483 In-Flight HTLCs?
The limitation of 483 in-flight HTLCs is tied to the maximum size of an on-chain Bitcoin transaction. If a channel had more than 483 HTLCs and needed to close, the resulting transaction would be too large to enforce on-chain.
The Magnitude of the Problem
According to Antoine Riard and Gleb Naumenko, an attacker could potentially jam the entire LN for only 500,000 to 3 million sats per month. By jamming just 20% of the channels (approximately 14,000 channels), the attacker could render the entire network unusable.

The Hybrid Approach to Solving Channel Jamming
Channel jamming has been a known issue since 2015, and many solutions have been proposed. However, this article focuses on the "hybrid" approach developed by Carla Kirk-Cohen, Clara Shik, and Sergei Tikhomirov from Chain Code Labs.
The Two Main Components
1. Unconditional Fees: This tackles "fast" jamming, where HTLCs fail instantly. 2. Reputation Scheme: This addresses "slow" jamming, where jams remain "in flight" for an extended period.
Just to clarify: fast jamming is a constant stream of HTLCs that fail instantly (think of a machine gun), while slow jams remain “in flight” for hours or even days (more like a hostage situation).
1. Unconditional Fees
In this approach, a fee is levied unconditionally, irrespective of whether the payment fails or succeeds. According to simulations, a mere 2% increase in fees would fully compensate routing nodes for any jamming attacks. So, for example, if a normal payment fee was 100 sats, an additional 2 sats upfront on all payments would be sufficient.
2. Reputation Scheme
The reputation scheme is localized, meaning nodes only assign reputation to their immediate peers. This reduces complexity as it requires no network-wide coordination. Nodes can also "endorse" payments, making payments from high-reputation peers low-risk and those from low-reputation peers high-risk.
By using a combination of slot bucketing and this reputation scheme, the number of "in-flight" high-risk payments can be limited, preventing full channel jamming.
Conclusion
The hybrid approach combines unconditional fees for fast-jamming and a reputation scheme for slow-jamming. A modest upfront fee increase of 2% can effectively compensate routing nodes for fast-jamming attacks, while the local reputation scheme leverages HTLC endorsement and slot bucketing to ensure that a channel can never be fully jammed.
Further Information and Resources
Survey for Lightning Node Operators BOLT PR Summary of Full Research Paper Costs of Jamming
We hope this article has been informative. Special thanks to Carla Kirk-Cohen, Clara Shik, Sergei Tikhomirov, and Chaincode Labs for their invaluable contributions to solving this issue.