Flood-and-Loot Attack

What Is a Flood-and-Loot Attack?

A flood-and-loot attack is a systemic attack against the Lightning Network that exploits the relationship between on-chain block space and off-chain channel enforcement. The attacker deliberately congests the Bitcoin blockchain by force-closing a large number of channels at the same time, creating enough on-chain traffic to prevent victims from broadcasting their penalty transactions before the timelock windows expire.

The attack was formalized in the 2020 paper "Flood & Loot: A Systemic Attack On The Lightning Network" by Jona Harris and Aviv Zohar of The Hebrew University of Jerusalem, presented at the ACM Conference on Advances in Financial Technologies (AFT '20). Their research demonstrated through simulation that an attacker simultaneously targeting as few as 85 channels could guarantee theft of funds, assuming no competing blockchain transactions.

Unlike isolated channel attacks, the flood-and-loot attack is systemic: it weaponizes the shared resource of Bitcoin block space against multiple victims simultaneously. The more channels the attacker targets, the more congestion they create, and the higher their probability of success.

How It Works

The attack proceeds in two distinct phases, each exploiting a different property of the Lightning Network's security model.

Phase 1: Flood

The attacker operates two Lightning nodes: a source node and a target node that are not directly connected to each other. The source node opens channels with victim routing nodes positioned along paths to the target node. Once channels are established, the attacker executes the following steps:

1. The source node routes the maximum number of HTLC payments through victim nodes toward the target node, filling each channel with pending HTLCs
2. The target node receives the HTLCs and returns the payment preimages to the source node
3. The source node refuses to resolve the HTLCs with the victim nodes, despite knowing the preimages
4. Victim nodes, unable to resolve the HTLCs off-chain, are forced to close their channels on-chain
5. The mass channel closures flood the Bitcoin mempool with commitment transactions and HTLC-claim transactions

The key insight is that each Lightning channel can hold hundreds of concurrent HTLCs. LND, for example, allows up to 483 concurrent HTLCs per channel. By filling channels across dozens of victims, the attacker generates thousands of transactions that must all compete for limited block space.

Phase 2: Loot

With the blockchain congested from the flood of closing transactions, the attacker exploits the time-bounded nature of HTLC resolution:

1. Victims need their HTLC-timeout transactions to confirm before the timelock expires so they can reclaim their funds
2. The attacker uses replace-by-fee (RBF) to strategically manipulate fee rates, ensuring victim transactions are deprioritized
3. When victim timelocks expire without confirmation, the attacker broadcasts their own HTLC-success transactions claiming the funds

The attacker benefits from an asymmetric advantage: they know exactly when the timelocks expire and can time their transactions accordingly, while victims must compete blindly in a congested fee market.

Attack Parameters

The original research identified several implementation-specific parameters that affect the attack's feasibility:

In their simulation with 100 attacked channels, the researchers found the attacker successfully stole 7,402 out of 48,300 HTLC payments. At the time of publication, 95% of Lightning nodes accepted channel-opening requests from unknown nodes, making the setup phase trivial.

Simplified Attack Flow

Attacker Source ──HTLC──▶ Victim Node ──HTLC──▶ Attacker Target
                                  │
           ┌──────────────────────┘
           │
           ▼
Target reveals preimage to Source
Source withholds preimage from Victim
Victim force-closes channel on-chain
           │
           ▼
Blockchain congested with closing transactions
Victim's HTLC-timeout tx cannot confirm
Timelock expires → Attacker claims funds

Mitigations

The original paper proposed eight mitigations. Several have since been implemented across Lightning Network software, though none fully eliminates the attack on its own.

Anchor Outputs

Anchor outputs allow either party to bump the fee on a commitment transaction after it has been broadcast using child-pays-for-parent (CPFP). This counters the attacker's fee-manipulation strategy by letting victims dynamically increase their transaction priority. Anchor outputs are now deployed in all major Lightning implementations.

Package Relay

Package relay is a Bitcoin Core relay policy that allows nodes to evaluate the feerate of a parent transaction together with its children. This ensures that a low-fee commitment transaction can still propagate through the network if accompanied by a high-fee child transaction. Combined with v3 transaction policy, package relay significantly strengthens victims' ability to get their justice transactions confirmed under congestion.

Watchtower Services

Watchtowers are third-party services that monitor the blockchain on behalf of Lightning users and broadcast justice transactions if a counterparty publishes a revoked state. Watchtowers reduce the risk by ensuring that even if a victim is offline during the attack, their penalty transactions are still submitted. However, watchtowers face the same block space congestion as victims during a flood-and-loot attack.

Reduced HTLC Limits

Lowering the max_accepted_htlcs parameter reduces the number of HTLCs an attacker can stack in each channel, limiting the flood's intensity. Operators running routing nodes can configure this parameter to balance routing throughput against attack exposure.

Longer Timelocks and Earlier Closing

Increasing the HTLC expiry delta or closing channels earlier (higher commitment broadcast delta) gives victims more blocks to get their transactions confirmed. Eclair's default of 144 blocks for HTLC expiry provides substantially more buffer than LND's 40 blocks, though longer timelocks also increase capital lockup for routing nodes.

Why It Matters

The flood-and-loot attack reveals a fundamental tension in penalty-based payment channel designs: security depends on the ability to publish transactions on-chain within a time window, but block space is a shared and finite resource. An attacker who can saturate that resource undermines the enforcement mechanism that keeps channels honest.

This has implications for how layer-2 protocols are designed. Payment channel networks like Lightning inherit a dependency on timely on-chain access, which creates a class of attacks that alternative scaling approaches can avoid. Statechains-based protocols like Spark, for example, transfer ownership of UTXOs through cooperative key signing rather than penalty-based channel closures. Since there are no revoked states to publish and no justice transactions to race, the flood-and-loot attack vector does not apply.

For Lightning routing node operators, the attack underscores the importance of configuring conservative HTLC limits, running watchtower services, and keeping node software updated with the latest mitigations like anchor outputs and package relay support.

Related Attack Vectors

The flood-and-loot attack belongs to a broader family of Lightning Network attacks that exploit HTLC mechanics and on-chain enforcement:

• Channel jamming: locks up channel liquidity by sending payments that are never resolved, degrading network capacity without requiring on-chain congestion
• Replacement cycling: disclosed in October 2023, this attack uses RBF to cycle victim transactions out of the mempool entirely, stealing HTLC funds even without blockchain congestion
• Time-bandit attack: exploits blockchain reorganizations to reverse settled channel states, though this requires significant mining power
• Transaction pinning: prevents victims from fee-bumping their transactions by exploiting mempool relay policies, a technique the flood-and-loot attacker can combine with the flood phase

Risks and Considerations

No Confirmed Real-World Exploitation

As of 2026, no confirmed instances of a flood-and-loot attack have been documented on the Lightning Network mainnet. The attack was responsibly disclosed to the developers of LND, C-Lightning, and Eclair before the paper's publication. However, the attack remains theoretically viable, and improvements to Lightning's security model continue to address the underlying vulnerabilities.

Attacker Cost and Risk

The attack is not free. The attacker must open channels with real Bitcoin, pay on-chain fees for channel openings and closures, and risk losing those fees if the attack fails. The cost scales with the number of targeted channels. However, if successful, the stolen HTLC funds can significantly exceed the attacker's costs.

Evolving Defenses

The Lightning Network's defense against flood-and-loot attacks has improved substantially since the 2020 paper. Anchor outputs, package relay, and v3 transaction policies each address different aspects of the attack. The combination of these mitigations makes the attack considerably harder to execute profitably, though no single defense fully eliminates the underlying vulnerability of competing for finite block space.

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.