Channel Jamming
Lightning's HTLC-based forwarding has DoS vulnerabilities where malicious senders block honest payments without paying for the disruption.
Two main variants
Slow-jam (resource jamming)
Attacker sends large HTLCs that fail to settle until close to CLTV expiry, then fails them. During the wait, the channels' HTLC slots
- liquidity are tied up.
Cost to attacker: nothing — failed HTLCs cost zero (no fee paid for failed payments).
Damage: legitimate payments rejected for "no liquidity" / "no slot available" while attacker's HTLCs sit.
Fast-jam (channel exhaustion)
Attacker rapidly cycles HTLCs (send → fail), filling and freeing slots faster than honest senders can grab them.
Less effective than slow-jam but still degrades service.
Why this works
Lightning has no payment for failed HTLC routing:
- Successful payment: each hop earns its forwarding fee.
- Failed payment: each hop refunds, no fee charged.
- Attacker exploits this asymmetry.
Mitigation 1: Upfront fees (proposal)
Charge a small fee BEFORE forwarding. Even failed HTLCs cost the sender. Returned to sender on success (or kept regardless).
Proposed in various BLIPs; not yet active.
Mitigation 2: Reputation
Forwarders track which upstream peers send HTLCs that frequently fail. Penalize bad senders by:
- Lower forwarding priority.
- Higher upfront fee.
- Outright rejection.
Implementations:
- LSPs apply per-customer reputation.
- LDK has experimental reputation tracking.
Signalling layer:
bLIP-4
"Experimental Endorsement Signaling" (Carla Kirk-Cohen) is listed Active
in the lightning/blips repo as of September 2026. It defines an
experimental endorsed TLV (type 106823) on update_add_htlc: the
original sender sets endorsed=7 when it expects the payment to resolve
immediately and 0 otherwise, and forwarders relay or re-set the signal at
their discretion. Deliberately data-gathering only — nodes MUST NOT use
endorsed in resource allocation for the duration of the experiment,
whose experiment_end is unix 1767225600 (1 January 2026). Observable
state as of September 2026: experiment_start is still the literal
"TODO: set once feature bit is widely deployed" and that
experiment_end has already elapsed, while the bLIP's repo status is
unchanged at Active. The matching BOLT change (bolts PR #1071, "HTLC
Endorsement to Mitigate Channel Jamming") was closed unmerged in August
2025, so endorsement remains outside the BOLTs as of September 2026.
Measurement substrate: option_attribution_data (feature bits 36/37) is
in BOLT 9 as of September 2026. Attribution data rides as TLV type 1 on
update_fulfill_htlc and update_fail_htlc and carries
htlc_hold_times — up to 20 per-hop hold times in units of 100 ms, each
covered by the reporting hop's HMAC. That gives the sender a verifiable
per-hop latency record, which is the raw measurement any hold-time-based
reputation or hold-fee scheme needs.
Mitigation 3: Per-channel HTLC limits
Aggressive max_accepted_htlcs (default ~483) and max_htlc_value_in_flight_msat
limit damage per channel.
Trade-off: low limits also hurt legitimate MPP / micro-payments.
Mitigation 4: Hold fees
Charge per-hop a "hold fee" proportional to time × amount that the
HTLC is in flight. Long hold = larger fee. Defeats slow-jam.
The long-standing blocker is that there is no universal clock and no way to prove a message (the preimage) was delivered at a given moment, so "how long did you hold it?" is unprovable. Antoine Riard's Conditional Message Transfer Contract (CMTC), posted to Delving Bitcoin on 7 August 2026, is the first concrete construction that attacks that blocker. It is a Bitcoin Script construction, using adaptor signatures and timelocks on today's consensus rules, that lets two channel counterparties later prove whether a specific message was exchanged between them by a given block height — block height serving as the universal clock. The parties agree on a discrete temporal window and assign an "oracle-time" adaptor point to each point in it, so a withhold fee can be settled according to when the message was delivered. Three proof paths:
- Message transfer success: Bob delivers the preimage and Alice cryptographically acknowledges it; the two split the withhold fee according to delivery time.
- Liveness challenge: Alice is offline and cannot counter-sign; Bob exits the contract and recovers the locked funds minus an equilibrium penalty fee.
- Message transfer failure: Bob is offline or never delivers the message; Alice exits and takes the withhold fee.
Riard presents only an on-chain version and leaves lifting it into an off-chain channel (as extra tapscript leaves) to future work. He also states that the construction's cryptographic correctness and its cryptoeconomic equilibrium both need further analysis — treat it as a research prolegomenon, not a deployable design.
Status as of September 2026: research-stage. Not in any BOLT.
Mitigation 5: Channel jamming via stuckless payments
Stuckless = receiver provides cancellation token; if sender wants to abort, they can without keeping CLTV pending. Reduces slow-jam window.
Status: theoretical / spec-stage.
Real-world status
As of September 2026:
- Active jamming attacks exist but are not yet a major operational problem (small network, low incentive).
- Anticipated to become serious if/when LN scales 10-100x.
- Major LN routing nodes are starting to apply heuristic-based reputation systems.
- Spec-side work is on measurement and signalling (attribution data, bLIP-4 endorsement), not yet on enforcement; the economic mitigations (upfront fees, hold fees/CMTC) remain research.
Compared to replacement cycling
- Replacement cycling: attacks specific HTLC-timeout settlement on chain.
- Channel jamming: attacks live channels off chain by exhausting resources.
Different layers, different mitigations.