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.
Complete Step 1 // Required reading in the study plan above, then continue here. This closes Routing & Liquidity.
Step 2 — Core idea: griefing, probing, uptime
Builders shipping POS, wallets, or routing services inherit LN’s adversarial reality. Ignoring known griefing classes and past CVEs is negligence.
| Class | Idea |
|---|---|
| Congestion / jamming | Hold HTLCs / paths to consume capacity and degrade success |
| Probing | Learn balances via success/failure of trial payments |
| Offline breach | Broadcast old state while victim is offline — watchtowers help |
| Shared CVEs | Multi-implementation bugs — patch process matters |
Loading diagram…
Done when: You can explain why locking liquidity without theft still damages a product.
Step 3 — Tabletop (lab)
Pick congestion, probing, or offline breach on a 3-node mental/Polar graph. Attacker steps → detections → two mitigations ranked by cost vs impact.
Common mistakes
- Marketing “Lightning is private” without caveats
- Running routing nodes with no capacity/HTLC metrics
- Skipping patch discipline because “it’s just testnet”
Done when: Lab evidence (tabletop + alerts + mitigations) is complete. Complete the chapter quiz when prompted.
Next lesson
LND (Implementation) — gRPC, REST, and macaroon authentication.