Jamming Attack (LN)

A jamming attack on the Lightning Network is when an attacker deliberately ties up channel liquidity by initiating payments that are designed to fail at the last moment - tying up HTLCs in pending state until they time out. The attacker doesn't lose money (the payment unwinds), but legitimate payments through those channels can't get through during the jam window.

The attack mechanics:

1. Attacker initiates a Lightning payment along a target route, using a fake or non-redeemable payment hash.
2. Each hop along the route locks the relevant channel capacity in a pending HTLC.
3. The payment can't complete (the receiver can't reveal a preimage they don't have).
4. The HTLCs remain locked until their timeout expires - typically tens of minutes to hours.
5. During the lockup, legitimate users trying to route through those channels see "insufficient capacity" failures.

There are variants:

• Slow jamming. Use many small HTLCs to exhaust a channel's HTLC count limit (typically 483 in-flight HTLCs per channel direction). Channels reach capacity in HTLC slots rather than in BTC.
• Quick jamming. Use larger HTLCs to exhaust the BTC capacity.
• Targeted jamming. Attack specific routes to disrupt competitors or extract some other operational advantage.

Defenses being researched and deployed:

• Upfront fees. Make routing attempts cost something (small but non-zero) so jamming has real cost. Discussed in the LN community for years; deployment is gradual.
• Reputation systems. Nodes track peers that frequently initiate non-completing payments and degrade or drop those connections.
• Channel jamming detectors. Real-time monitoring of HTLC patterns to identify likely attacks. See Jammed HTLC Detector.

Jamming is one of the open security problems in Lightning. Not theoretical - it has been observed in the wild - but also not catastrophic. The defenses are improving. The protocol is being hardened. The cat-and-mouse continues.