Security / DoS Analysis

Channel Jamming
Attack & Defense Simulator

An interactive deep-dive into the most dangerous denial-of-service vector on the Lightning Network — how attackers exploit HTLC slot limits, and how the community is fighting back.

483
Max HTLCs / channel
<$0.01
Cost to jam 1 hour
2016
Max timeout blocks
~$125
Attack entire network
1
What is Channel Jamming?
How attackers exploit the HTLC slot limit to deny service at near-zero cost

Attack Mechanism

1
Attacker creates a circular payment route: Attacker → Alice → Bob (victim) → Carol → Attacker
2
Attacker sends many HTLC payments but controls the final hop — so they can never resolve the payment
3
Each pending HTLC locks up one of Bob's 483 HTLC slots AND locks the corresponding liquidity
4
Once all slots are exhausted, legitimate payments through Bob's channel fail immediately — channel is jammed
5
After HTLC timeout expires, attacker lets the payment fail (pays nothing net) and repeats immediately
Type 1

Fast Jamming

The attacker floods the target channel with maximum-volume HTLC spam. By sending 483 tiny HTLCs simultaneously, all HTLC slots are exhausted instantly — even if the liquidity is barely touched. The channel becomes completely unusable for legitimate traffic.

Cost is near-zero: the attacker only needs the base fee multiplied by the number of hops for each wave. Without upfront fees, this approaches 0 sats total cost per attack cycle.

Slot exhaustion 483 HTLCs Instant impact Cyclic route
Type 2

Slow Jamming

Fewer HTLCs, but each carries a maximum CLTV timeout (up to 2016 blocks ≈ 14 days). The attacker locks up large amounts of liquidity for extended periods. Even 10–50 HTLCs can render a channel economically useless by consuming its routing capacity.

The economics are devastating: holding 1 BTC of liquidity hostage for two weeks costs the attacker roughly $0 in fees (no upfront fee mechanism exists today), while the victim loses all routing revenue.

Liquidity lock 2016 blocks ~14 days Few HTLCs needed
Property Fast Jamming Slow Jamming
Resource exhausted HTLC slots (483 limit) Channel liquidity
HTLCs needed 483 (maximum) 10–50 sufficient
Duration per wave Seconds to minutes Up to 14 days
Attacker cost (no upfront fee) ~0 sats ~0 sats
Detectability Obvious (slot exhaustion) Hard (looks like stuck payments)
Main defense vector Rate limiting, endorsement Hold fees, reputation
2
Live Attack Simulation
Watch HTLC slots fill up in real-time — toggle between fast and slow jamming modes
Slots: 0 / 20 filled  |  Mode: Fast Jamming
Alice sender Bob victim Carol exit ATK ATK Alice–Bob channel Bob–Carol channel
CHANNEL JAMMED
All 483 HTLC slots exhausted — legitimate payments rejected
Bob's HTLC Slots (simplified: 20 slots represent 483 maximum)
Empty slot
Fast-jam HTLC (pending)
Slow-jam HTLC (long timeout)
Legitimate HTLC
Fast Jamming — What you're seeing

Attacker sends HTLC waves at maximum rate. Each red block is a pending HTLC held hostage. Within seconds, all 483 slots fill and Bob's channel becomes unusable. The attacker resets after timeout and repeats indefinitely.

3
Attack Cost Calculator
Compare attacker expenditure vs. routing revenue destroyed — adjust parameters to see the economic asymmetry
1,000
Amount per HTLC. Smaller = more slots fillable; larger = more liquidity locked
5
Number of victim channels attacked simultaneously
24 hrs
Duration in hours (1 hr to 14 days / 336 hrs)
0.00%
Upfront fee as % of HTLC amount (0 = current Lightning; 1% = proposed defense)
200
Victim's average routing fee in parts-per-million (industry avg ~100-500 ppm)
Attacker Cost
0
sats total
Victim Revenue Lost
0
sats routing fees
Cost / Damage Ratio
0.001
Lower = more devastating for attacker. 0.001 means $1 causes $1,000 in damage.
Attack Feasibility
Expensive Moderate Cheap Free
TRIVIALLY CHEAP
Key Insight: Without upfront fees, the attacker pays ~0 sats to jam for hours. The only "cost" is the opportunity cost of locked capital — but since the attacker controls both ends of the loop, they can recycle their own funds indefinitely.
4
Defense Mechanisms
Four proposed and deployed strategies — click each card to expand details
🏅
HTLC Endorsement
Trusted-peer priority slot allocation
🟡 BOLT #1045

Endorsement is a local reputation signal carried as a 1-bit flag in the update_add_htlc message. When a peer endorses an HTLC, they stake their local reputation on it. Nodes allocate the majority of their HTLC slots only to endorsed HTLCs.

Endorsed HTLCs get 90% of 483 slots (≈434 slots)
Unendorsed HTLCs limited to 10% (≈48 slots) — attacker can't fill all
Endorsement is not forwarded blindly — each node independently decides whether to endorse based on local peer history
Bootstrap problem: new channels have no endorsement history, creating a chicken-and-egg issue
Endorsement Propagation
Trusted Peer
Bob (Router)
checks local rep
Carol
endorsed ✓
Unknown / Attacker
Bob (Router)
no local rep
Limited slots
unendorsed ✗

Reference: Unjamming Lightning (Bastien Teinturier et al.) — BOLT #1045 draft

💰
Upfront Fees
Economic penalty for holding HTLC slots
🟡 Under Research

The core asymmetry of jamming is that failure is free. Upfront fees force the attacker to pay regardless of payment outcome — turning the attack from free into costly. There are two components:

Base upfront fee: Small flat fee paid when HTLC is forwarded, non-refundable on failure
Hold fee: Time-proportional component — the longer an HTLC is held, the more the sender pays
Challenge: routing nodes currently cannot tell legitimate stuck payments from jamming attacks
Risk: increases cost for legitimate payments that fail due to routing failures (unintended deterrence)
Attacker Cost vs. Hold Duration
1 min
10 min
1 hr
6 hrs
1 day
1 week
Hold fee accumulates over time → slow jamming becomes expensive

Without hold fees: slow jamming is free. With 0.1 sat/block hold fee: 14-day attack costs 201,600 sats per HTLC — making slow jamming prohibitively expensive.

🔀
Adaptive Rate Limiting
Per-peer circuit breakers and HTLC throttling
🟢 Partially Deployed

Rate limiting at the peer level can detect and throttle suspicious HTLC floods before they exhaust slot capacity. This is the most immediately actionable defense — some implementations already deploy it.

Per-peer HTLC rate limit: Maximum N HTLCs per peer per time window
Failed HTLC counter: Peers with high failure rates trigger throttling
Circuit breaker pattern: Temporary peer suspension after threshold breach
LND implementation: --max-pending-channels, --max-htlcs per channel flags
Circuit Breaker State Machine
CLOSED
normal routing
HALF-OPEN
rate limited
OPEN
peer suspended
Triggered by: HTLC failure rate > 80% within 10-minute window, OR >50 pending HTLCs from single peer

Limitation: sophisticated attackers can stay below rate limits while still causing significant damage by targeting multiple channels simultaneously. Rate limiting alone is not a complete solution.

Reputation System
Local scoring of peer trustworthiness
🔴 Research Stage

Each node maintains a local reputation score for each direct peer, based on historical payment forwarding behavior. High-reputation peers get more HTLC slots; low-reputation or new peers are rate-limited.

Success rate: % of forwarded HTLCs that resolved successfully (vs. failed/expired)
Hold time: Average time-to-resolution — slow resolution penalizes reputation
Volume consistency: Large sudden spikes are penalized; steady volume builds trust
Revenue contribution: Peers generating more routing revenue earn higher reputation
Local Reputation Scores (example)
Peer A
0.88
Peer B
0.62
New Node
0.10
Attacker
0.05

Bootstrap Problem: New legitimate nodes have zero reputation and get limited slots — creating a catch-22. Solutions under research include staked reputation (pay-to-build) and cross-node reputation attestation (requires trust).

Reference: Routing Bitcoin: Congestion and Stability — Avarikioti et al.; Unjamming Lightning reputation model

Research consensus: No single mechanism is sufficient. The most promising approach combines HTLC Endorsement (fast jamming defense) + Hold Fees (slow jamming defense) into a unified framework. The Unjamming Lightning paper (Teinturier, Pickhardt et al.) shows this combination can make jamming economically unviable without significantly harming legitimate users.
5
Game Theory: Payoff Matrix
Strategic interaction between attacker and defender — click any cell to see analysis
Attacker Strategy ↓
Defender Strategy →
No Defense Endorsement Only Upfront Fee Only Combined Defense
No Attack
0
0
0
−c
0
−c
0
−2c
Fast Jamming
+10
−10
+3
−3
−2
−1
−5
0
NE
Slow Jamming
+8
−8
+7
−7
−3
−2
−6
0
NE
Combined Attack
+12
−12
+4
−5
−2
−3
−8
−1
NE

Reading the matrix: Top number = attacker payoff (green = profitable, red = loss). Bottom number = defender payoff/loss. NE = Nash Equilibrium cell. Payoffs are normalized utility units, not literal sats.

Key result: Without any defense, fast jamming dominates (payoff +10). With combined endorsement + upfront fees, all attack strategies become unprofitable (negative payoff) while defense cost is small (−1 to −2c). This shifts the Nash Equilibrium to "No Attack + Combined Defense."

6
Real-World Impact Metrics
Quantified attack parameters from research papers and BOLT specifications
483
HTLCs max per channel
BOLT #2 hard limit. Both directions combined. Exhausting this makes the channel 100% unusable regardless of liquidity.
<$0.01
Cost to jam 1 hour
Without upfront fees, attacker pays only routing fees on successful payment waves. With cyclic routes, net cost approaches zero.
~$125
Estimated cost to attack entire Lightning Network
From Bribe & Fork and related jamming analysis papers. The network's hub-and-spoke topology concentrates vulnerability.
14 days
Maximum HTLC timeout
2016 blocks × 10 min/block. Slow jamming can hold liquidity hostage for the full duration with minimal cost today.
Who is most vulnerable?
High-liquidity hub nodes (carry most routing traffic)
Routing nodes in competitive fee markets (targeted to eliminate competition)
LSPs (Lightning Service Providers) managing channels for many users
Watchtowers during high-volume periods when HTLC slots fill naturally
Leaf nodes (small private channels, fewer routes to jam)
Why hasn't it happened at scale?
🤔
Lightning is still relatively small — large-scale jamming isn't yet economically motivated
🔍
Technical barriers: requires managing many concurrent channels and understanding the network topology
⚠️
Researchers have demonstrated feasibility in controlled experiments — not yet in wild
🛡️
Some rate limiting already deployed (LND, CLN) provides partial protection
📈
Risk increases as network value and routing revenue grows — making fixes urgent
Key Research Papers: Tikhomirov et al. — Quantitative Analysis of LN (2020)  |  Pérez-Solà et al. — Lockdown Protocol (2020)  |  Teinturier et al. — Unjamming Lightning (2022) (BOLT #1045 basis)  |  Avarikioti et al. — Ride the Lightning: Routing Congestion (2020)  |  Beres et al. — Cryptoeconomic Security Analysis (2021)