RoadmapsProjects
Sign in./start

Learn

RoadmapsProjects

Contribute

DiscoverIssues

Account

Sign in./start-building

Become an Open Source Builder. Learn. Build. Contribute.

Learn

RoadmapsProjectsStart Building

Contribute

DiscoverIssues

Account

Sign inDashboardSettings

Legal

PrivacyTerms

© 2026 Pull // all rights reserved

PrivacyTerms

lesson // lightning

Lightning Attack Surface

Congestion, channel probing, watchtower incentives, and lessons from real LN CVEs — adversarial thinking for Lightning builders.

advanced7 days

Public lesson — sign in to track progress on this roadmap.

./sign-in

On this page

Learning objectives

  • Describe payment-channel congestion / jamming style griefing at a conceptual level
  • Explain channel balance probing and privacy implications
  • List defensive practices and why watchtowers / uptime matter

study // plan

Lessons are primers. Depth comes from required reading, interactive labs, reflection, and a hands-on check with evidence — the BOSS study pattern.

Research on Bitcoin Search
Lightning attack surfacechannel jamming

Required reading

  • docsPayment channel congestion discussion
  • articleOn the Difficulty of Hiding the Balance of Lightning Network Channels
  • article2019 LND/CLN/Eclair CVE disclosure

Reflection prompts

  1. How can an attacker lock liquidity without stealing funds outright, and why is that still damaging?
  2. What does successful channel probing reveal, and how should wallet UX talk about LN privacy?
  3. After reading a historical multi-implementation CVE disclosure, what process change would you add to your release checklist?

Lab // Adversarial tabletop

Run a tabletop exercise for a 3-node Polar graph. Pick congestion, probing, or offline breach. Write attacker steps, defender detections, and product mitigations.

evidence required

  • ·One-page tabletop writeup with roles and timeline
  • ·List of metrics/alerts you would monitor
  • ·Two product mitigations ranked by cost vs impact

Lightning’s safety depends on timelocks, honesty assumptions, availability, and implementation correctness. Attackers may not need to steal immediately — locking liquidity, probing balances, or racing offline victims can still win.

Why this matters

Builders shipping POS, wallets, or routing services inherit LN’s adversarial reality. Ignoring known classes of griefing and past CVEs is negligence.

Congestion and jamming

Attackers can open paths or hold HTLCs to consume channel capacity, degrading payment success for others. Defenses are an active research and engineering area (limits, reputation, upfront fees, etc.).

Probing

Because routing reveals whether a payment can proceed, adversaries can probe channel balances more than naive privacy marketing suggests. Treat LN privacy as layered and incomplete.

Watchtowers and uptime

Revocation justice requires someone online to notice a breach. Watchtowers outsource detection; they do not remove the need for correct backups and timely justice transactions.

CVEs are part of the curriculum

Multi-implementation incidents (for example the 2019 disclosures affecting major daemons) show that interop + shared assumptions can fail together. Read disclosures for process lessons, not doom.

Defense in depth

Limits, monitoring, backups, towers, and conservative channel sizes beat clever one-off settings.

Common mistakes

  • Marketing “Lightning is private” without caveats
  • Running routing nodes with no capacity/HTLC metrics
  • Skipping patch discipline because “it’s just testnet”

further reading

  • bookMastering the Lightning Network

    Security / attacks overview

progress // sign in

Reading is public. Sign in to mark lessons complete, sync across devices, and unlock your roadmap.

./sign-in-to-track
prevFailure HandlingnextLND

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.