Routing Attack

What Is a Routing Attack?

A routing attack is any deliberate exploitation of the Lightning Network's payment routing infrastructure. Because Lightning payments traverse multiple hops between sender and receiver, each intermediary node becomes a potential target. Attackers can degrade routing performance, leak private balance information, or profit unfairly by manipulating how payments flow through the network.

Unlike on-chain Bitcoin attacks that require significant hash power or capital, many routing attacks are cheap to execute. The Lightning Network relies on nodes voluntarily forwarding payments and locking liquidity in HTLCs. This cooperative model creates attack surfaces that traditional payment networks avoid through centralized gatekeeping. Understanding these attacks is essential for node operators, wallet developers, and anyone building on Lightning infrastructure.

Routing attacks fall into three broad categories: jamming attacks that deny service, probing attacks that violate privacy, and fee manipulation attacks that distort economic incentives. Each exploits a different aspect of Lightning's onion-routed payment architecture.

How It Works

Channel Jamming

Channel jamming is the most studied routing attack and remains the Lightning Network's most significant unresolved vulnerability. The attacker sends payments through a target node's channels but deliberately prevents those payments from completing. This locks the target's inbound liquidity and HTLC slots, preventing the node from routing legitimate payments.

There are two distinct variants of channel jamming, each exploiting a different resource constraint:

Liquidity Jamming

Liquidity jamming targets channel capacity. The attacker routes large payments (or many medium-sized payments) through the victim's channels. By using hodl invoices or deliberately slow settlement, the attacker keeps HTLCs pending for as long as the timelock allows.

Consider a routing node with a 1 BTC channel. If an attacker routes 0.9 BTC through it via a hodl invoice, 90% of the channel's capacity is locked for the HTLC's entire duration. Legitimate payments requiring more than 0.1 BTC through that channel will fail.

# Liquidity jamming: attacker controls both endpoints
# Attacker node A sends to attacker node B through victim V

A --[0.9 BTC HTLC]--> V --[0.9 BTC HTLC]--> B

# B (attacker) holds the HTLC without settling
# V's channel capacity is 90% locked
# Legitimate payments through V fail due to insufficient liquidity

# Cost to attacker: only the on-chain fees to open channels
# Damage: V cannot route for hours until HTLC times out

The attacker controls both the sending and receiving nodes. Since the payment never completes, no routing fees are paid. The attack cost is limited to the capital the attacker must lock in their own channels and the on-chain fees to open them.

Slot Jamming

Slot jamming is more efficient than liquidity jamming because it targets HTLC slots rather than capacity. Each Lightning channel can only hold a limited number of concurrent HTLCs (typically 483 per direction, as defined in the BOLT specifications). The attacker fills these slots with tiny payments that never resolve.

Because the minimum HTLC amount can be as low as 1 satoshi, an attacker can jam 483 slots using fewer than 483 satoshis of locked capital per channel. This makes slot jamming extremely cheap: a few hundred sats can completely disable a channel's routing ability.

# Slot jamming: 483 tiny HTLCs fill all available slots
# Each HTLC locks 1 sat but consumes one slot

for i in range(483):
    send_htlc(
        amount=1_sat,
        route=[attacker_A, victim, attacker_B],
        hold=True  # Never settle or fail
    )

# Result: victim's channel has 0 available HTLC slots
# No new payments can be routed, regardless of capacity
# Total capital locked: ~483 sats (< $0.50)

Balance Probing

Balance probing attacks exploit the error messages returned by failed payment attempts to determine channel balances. Although Lightning uses onion routing to protect payment paths, the error codes reveal whether a channel had sufficient balance to forward a specific amount.

The attacker constructs payments with invalid payment hashes (ensuring they always fail) and sends them through target channels at varying amounts. By performing a binary search on the amount, the attacker can determine the exact balance of any channel within a few dozen attempts:

1. Send a probe for 50% of the channel capacity
2. If the error is "insufficient balance," the balance is below that amount
3. If the error is "invalid payment hash," the balance is above that amount (the payment reached the destination but failed on the hash)
4. Adjust the probe amount and repeat until the balance is known precisely

This technique reveals the distribution of funds in a channel, which is supposed to be private. Knowledge of channel balances can be used to deanonymize payments, front-run routing opportunities, or identify high-value targets for other attacks. Research into PTLCs and blinded paths may reduce probing effectiveness over time.

Fee Manipulation

Fee manipulation attacks exploit the dynamic nature of Lightning routing fees. Nodes can change their fee policies at any time, and the network relies on gossip to propagate these updates. Attackers exploit the delay between fee changes and network-wide awareness:

• Fee sniping: a node advertises low fees to attract traffic, then raises fees after payments are in-flight, profiting from the stale routing information other nodes use
• Fee undercutting: systematically underbidding competitor nodes to capture routing volume, then raising fees once competitors close unprofitable channels
• Griefing via fee updates: rapidly changing fees to cause widespread routing failures as senders construct routes using outdated fee information

These attacks are harder to detect than jamming because they resemble normal fee adjustments. The distinction between aggressive business strategy and malicious manipulation is often ambiguous.

Use Cases

Understanding routing attacks matters in several practical contexts:

• Node operator defense: routing node operators must understand jamming and probing to configure appropriate channel policies, HTLC limits, and fee structures that minimize exposure
• Wallet and application design: Lightning wallets need to handle routing failures gracefully, using techniques like multi-path payments and trampoline routing to route around jammed or probed channels
• Protocol development: awareness of attack vectors directly informs proposals like PTLCs and HTLC endorsement that aim to strengthen the network
• Security auditing: liquidity management services and Lightning Service Providers must model routing attacks when evaluating their risk exposure
• Academic research: routing attacks provide formal models for analyzing incentive compatibility and game theory in payment channel networks, informing the design of next-generation protocols

Mitigations

Upfront Fees

The most discussed mitigation for channel jamming is upfront fees: a small, non-refundable payment charged for forwarding an HTLC, regardless of whether the payment succeeds. This makes jamming economically costly because each held HTLC now has a price.

The challenge is calibration. Fees high enough to deter jamming may also discourage legitimate payments, especially multi-hop routes where upfront fees accumulate at each hop. Research continues on models where upfront fees scale with hold time rather than being fixed.

HTLC Endorsement

HTLC endorsement is a reputation-based approach where nodes vouch for the quality of forwarded payments. A node marks an HTLC as "endorsed" based on the history of the peer that sent it. Nodes reserve a portion of their HTLC slots and liquidity exclusively for endorsed HTLCs.

This creates a two-tier system: endorsed payments get priority access to resources, while unendorsed payments use only unreserved capacity. An attacker who jams using unendorsed HTLCs can only consume the unreserved portion. To obtain endorsement, the attacker must build a positive reputation through legitimate forwarding, which has a real cost.

Circuit Breakers

Circuit breakers are local node policies that automatically restrict traffic from peers exhibiting suspicious behavior. If a peer sends an unusual volume of HTLCs that fail or take too long to resolve, the circuit breaker limits or blocks further HTLCs from that peer.

# Example circuit breaker policy (conceptual)
circuit_breaker:
  max_pending_htlcs_per_peer: 30
  max_htlc_hold_time: 300  # seconds
  failure_rate_threshold: 0.8  # 80% failure triggers block
  cooldown_period: 3600  # 1 hour block after trigger

Circuit breakers are already deployable today as node plugins, making them the most practical immediate defense. However, they are reactive rather than preventive and can be circumvented by attackers who distribute their activity across many nodes.

Channel Reserve and Policy Tuning

Node operators can reduce their exposure by tuning channel parameters. Increasing the channel reserve reduces the amount of liquidity available for routing (and thus for jamming). Setting lower maximum HTLC values, shorter CLTV deltas, and higher minimum HTLC amounts all narrow the attack surface at the cost of reduced routing capability.

Risks and Considerations

Channel jamming is often described as the Lightning Network's most critical unsolved problem. The fundamental challenge is asymmetry: the cost to the attacker is near zero (only opportunity cost of locked capital), while the damage to routing nodes can be severe (complete loss of routing revenue and service disruption).

Privacy-focused mitigations can conflict with anti-jamming measures. For example, upfront fees require identifying the payer (at least to the first hop), and reputation systems inherently reduce anonymity. The tension between privacy and accountability shapes much of the ongoing research in this space.

Probing attacks highlight a broader challenge with Lightning privacy. While onion routing protects the identity of senders and receivers, it does not prevent observation of channel states. Solutions like blinded paths and payment decorrelation through PTLCs address different facets of this privacy gap but introduce their own complexity.

For builders on Lightning, routing attacks are not theoretical: they have been demonstrated in research and observed on the live network. Any application relying on Lightning routing should incorporate retry logic, path diversity via atomic multipath payments, and monitoring for abnormal routing behavior.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.