Griefing Attack

What Is a Griefing Attack?

A griefing attack is a denial-of-service strategy in payment channel networks where an adversary intentionally locks up a victim's channel capacity by initiating payments they never intend to complete. Unlike theft or fraud, the attacker does not profit financially: the sole objective is to cause disruption. The term "griefing" originates from online gaming, where players harass others purely for the sake of causing grief.

In the context of the Lightning Network, griefing attacks exploit the way HTLCs (Hash Time-Locked Contracts) work. When a payment is routed through intermediate nodes, each node locks liquidity in an HTLC until the payment either settles or times out. An attacker can abuse this mechanism by holding payments in limbo, preventing the locked funds from being used for any other purpose.

Griefing is the broader category of attack; channel jamming is a specific and well-studied variant. Both remain among the most discussed unsolved problems in Lightning Network security research.

How It Works

A griefing attack follows a straightforward sequence that exploits the normal mechanics of multi-hop Lightning payments:

1. The attacker controls at least two nodes on the network (or one node and a cooperating endpoint)
2. The attacker constructs a payment route that passes through the victim's channel, sending from one of their nodes to the other
3. At the receiving end, the attacker uses a hodl invoice or simply refuses to release the preimage, leaving the HTLC unresolved
4. The victim's node holds the HTLC open, with liquidity locked until the timelock expires
5. The attacker repeats this process across multiple channels or with many small HTLCs to maximize disruption

During the hold period, every node along the route has capital frozen in pending HTLCs. The victim cannot use those funds for routing other payments, effectively reducing their earning potential and overall network throughput.

The Cascade Effect

Multi-hop routing amplifies the damage. Each hop in a Lightning payment path decrements the CLTV expiry delta by a node-specific value (typically 34 to 144 blocks depending on the implementation). A payment routed across 20 hops, each with a 100-block delta, could lock funds for up to 2,000 blocks: approximately two weeks.

The maximum absolute CLTV expiry for a complete payment path defaults to 2,016 blocks under the BOLT specification. This means a single malicious payment can theoretically freeze liquidity along its entire route for roughly 14 days.

Technical Parameters

Several protocol-level constants define the attack surface:

Griefing vs. Channel Jamming

Channel jamming is the most common form of griefing attack and comes in two variants:

• Slot jamming: the attacker fills all 483 HTLC slots with minimum-value payments. This is extremely cheap since total capital required is only 483 times the minimum payment amount, regardless of the channel's capacity
• Amount jamming: the attacker locks up all available liquidity in a channel by routing large-value payments. This requires more capital from the attacker but fewer individual HTLCs

Slot jamming is generally the more economically efficient vector. Research estimates that an attacker could paralyze most of the liquidity in the Lightning Network for three days while spending less than half a bitcoin.

The Cost Asymmetry Problem

The fundamental challenge of griefing attacks is the asymmetry between what the attacker pays and what the victim loses:

• Attacker cost: nearly zero. The only expense is the opportunity cost of capital locked in the attacker's own channels, plus the cost of running a script. Through circular routing optimizations, the attacker's opportunity cost can be reduced by roughly 20x
• Victim cost: substantial. All liquidity in jammed channels is frozen and cannot earn routing fees. If the victim resorts to a force-close (the only on-chain recourse), the costs are significant: at 50 sat/vbyte with 483 pending HTLCs, force-closing a single channel costs approximately one million sats
• Network cost: degraded routing reliability, higher payment failure rates, and reduced throughput across the network as legitimate payments cannot find viable paths

This asymmetry makes griefing particularly difficult to deter. Traditional anti-spam mechanisms like fees are ineffective when the attacker's cost is already near zero and they have no financial motive to balance against.

Mitigation Strategies

The Lightning development community has proposed several approaches to reduce the impact of griefing attacks. No single solution fully solves the problem, but each raises the cost or reduces the effectiveness of attacks.

Reputation Systems

A hybrid reputation-based approach has been under active development via BOLTs issue #1218. In this system, downstream nodes signal accountability for HTLC behavior, and nodes with strong reputations receive priority access to HTLC slots. The key property: to build enough reputation to fully occupy a channel's resources, an attacker must pay the target more than it would have earned during normal operation.

Simulation results published in October 2025 showed this approach adequately protects against both resource exhaustion and manipulation attacks. Read-only implementations are under review in both LDK and LND.

Circuit Breakers

Circuit breakers are a network-level defense that monitors and limits HTLC forwarding behavior. When a node detects anomalous patterns (such as a sudden spike in pending HTLCs from a single peer), it can temporarily halt forwarding from that peer. This is analogous to electrical circuit breakers that trip under overload conditions.

The limitation is that circuit breakers work best when widely adopted: a single node running a circuit breaker protects itself, but the network benefits most when participation is broad.

Upfront and Hold Fees

A fee-based spam prevention approach proposed in March 2025 introduces a two-tier fee structure:

• Upfront fees: paid by senders to downstream nodes when initiating an HTLC, covering computation costs and slot allocation regardless of whether the payment completes
• Hold fees: charged to nodes that delay payments beyond a grace period, scaling with both delay duration and capital held. This directly targets the cost asymmetry by making long holds expensive for the party causing them

# Conceptual hold fee calculation
# hold_fee_rate: 2e-5 per hour (~19% annualized)
# amount_held: 1,000,000 sats
# hold_duration: 24 hours (beyond grace period)

hold_fee = amount_held * hold_fee_rate * hold_duration
# hold_fee = 1,000,000 * 0.00002 * 24 = 480 sats

# For 483 HTLCs held for 14 days:
total_cost = 483 * 1000000 * 0.00002 * 336
# total_cost = 3,245,760 sats (~$1,200 at current prices)

This approach is promising but requires protocol-level changes and introduces complexity around fee enforcement across multi-hop routes.

HTLC Slot Bucketing

Separating HTLC slot limits by payment value makes slot jamming as expensive as amount jamming. For example, payments under 100,000 sats might access only 150 of the 483 available slots, while larger payments access the remainder. Combined with two-stage HTLC processing, research shows the effective slot capacity can be increased to over 233,000.

How Spark Avoids Routing-Based Griefing

Spark takes a fundamentally different architectural approach that eliminates the conditions griefing attacks depend on. Instead of routing payments through a network of bidirectional channels with HTLCs, Spark uses statechains that transfer ownership of on-chain UTXOs by rotating cryptographic keys via FROST threshold signatures.

This design removes the attack surface entirely:

• No multi-hop routing: transfers involve direct delegation of on-chain funds between parties through Spark Operators, so there is no route for an attacker to manipulate
• No HTLC slots to exhaust: without HTLCs, there are no pending payment slots to fill and no timelocks to exploit
• No channel liquidity to lock: users hold virtual UTXOs (vTXOs) rather than maintaining channel balances, eliminating the concept of locked directional capacity
• Self-custody preserved: users retain control of their funds through pre-signed exit transactions, without exposure to routing-based attacks

For a detailed comparison of how different Layer 2 architectures handle these security tradeoffs, see the Bitcoin Layer 2 comparison research article.

Risks and Considerations

No Complete Solution Yet

Researchers broadly acknowledge that fully mitigating griefing while preserving the permissionless nature of the Lightning Network may be impossible. Every proposed solution involves tradeoffs: reputation systems risk centralizing trust, upfront fees add cost to legitimate users, and circuit breakers require broad adoption to be effective. The problem remains an active area of research.

Game-Theoretic Challenges

Academic analysis of griefing penalties (such as the HTLC-GP proposal) found that while penalty mechanisms can raise the attacker's budget by approximately 12x, they work under the assumption that participants are either fully honest or fully malicious. Real-world rational actors may behave differently, and designing efficient penalty protocols within Bitcoin's current scripting system remains an open challenge.

Broader Network Effects

Even when individual nodes deploy defenses, the network-wide impact of griefing can cascade. Forced channel closures triggered by griefing contribute to on-chain congestion, raise fee rates for all Bitcoin users, and can trigger further force-closes in a feedback loop. Understanding these second-order effects is essential for evaluating the true cost of griefing attacks beyond direct liquidity loss.

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.