Channel jamming

From Bitcoin Wiki
Jump to navigation Jump to search

Channel jamming is a denial-of-service attack on the Lightning Network in which an adversary occupies channel liquidity, pending-payment slots, or both, so that honest payments cannot be forwarded. The attacker can often recover the funds used in the attack after a delay and pay little or no forwarding fee, because a failed HTLC does not produce a success fee.

Each Lightning channel can hold only a limited number of in-flight HTLCs (483 is the usual maximum) and a limited amount of value in those HTLCs. While an HTLC is pending, the corresponding outbound balance and slot cannot be used for other payments. HTLCs are designed to wait on the order of hours because each hop needs a timelock gap that covers worst-case on-chain confirmation.

In 2015 this property was described as a loop attack: an attacker routes a payment to itself over many hops and delays settlement, so the same funds lock many times their value along the path. The attack is often split into liquidity jamming (occupying value along a path) and slot jamming (filling pending-payment slots with small HTLCs). The two forms can be combined. No Bitcoin consensus change is required; the attack uses existing HTLC and onion-routing rules.

The attacker constructs an onion-routed payment whose destination is itself or a colluding node, or whose final hop will fail after holding the HTLC. Intermediate nodes forward according to BOLT 4 and wait for a preimage, a failure, or the deadline. During that wait, honest traffic that needs those slots or that liquidity is rejected. Because onion routing hides the destination, a forwarding node cannot tell a jammer from an ordinary slow payment. Reputation based on node identity is weak: an attacker can open many cheap channels and discard a peer identity after it is down-ranked.

Proposed mitigations (none a deployed network-wide standard) include upfront or hold fees so occupying a path has a cost, local reputation or HTLC endorsement, fidelity bonds against cheap Sybil identities, and local rate limits outside the BOLT specification. Watchtowers address on-chain cheat detection, not forwarding DoS; some operators still combine always-on infrastructure with jamming defenses.

See also

External links