The Summer Lightning Broke (a Little)
Between July and October every Lightning implementation shipped security fixes, and Core Lightning's maintainers asked operators to restart their nodes offline until a fix shipped. A fifth of CLN nodes went dark within a day, force closes on their channels doubled, and half were back within a week. The rest of the network barely noticed: what decides how far a client bug reaches is whether it hits the hubs, not how many nodes run that client. Everything below comes from daily gossip snapshots and our own Bitcoin node.
Context
What happened
Dates are those of the public posts (UTC); each links to its source. The Jul 10 event is not a Lightning bug: we saw it in gossip — channels toward Tor-only nodes of every client were disabled at once — during a denial-of-service wave against Tor that cut the relays serving onion-service descriptors from 3,874 (Jul 9) to 1,780 (Jul 12). The BTCPay incident was an application-layer credential leak (macaroons), not an LND protocol bug. CLN's Aug 26 advice was to upgrade or restart with --offline, which keeps the node running and watching the chain but drops every peer; it circulated during the day and was posted publicly at 23:26 UTC.
Q1 · Did the outage show up?
Core Lightning went dark after the maintainers' call
Share of channels pointing at each client's nodes that their peers marked disabled, daily. When a node drops its connections, its peers disable their side of the channel, so a node restarted with --offline and a node shut down look the same. Other clients are the control group.
Table view
It was Tor-reachable CLN nodes that went dark
Q1 · Who complied, and how fast did they come back?
A fifth of CLN nodes went dark — ten times an ordinary day; a third of them were still dark five weeks later
Went dark after the call
CLN nodes by capacity quintile (dark on Aug 27, not on Aug 25)
Still dark, days after Aug 26
CLN nodes that went dark on Aug 27
Table view
Q2 · Did the incidents cause a closing wave?
The big force-close spikes were single operators — but force closes on CLN channels doubled
Every force close since May, read from the blockchain. Days when one node was party to 20+ force closes are mass-close events: an operator closing many channels at once. Read naively, they look like incidents.
Organic force-close rate, Aug 26 – Sep 8 vs. Jul 1 – Aug 25
Per 1,000 open channels involving each client · 1.0× = no change
Mass-close events, by client of the node at the center
Who drove the early-August closing wave
Mostly cooperative closes by large operators. Kraken moved to a new Lightning node on Aug 12, so its closes are a migration, not a reaction to an incident.
Table view — all mass-close events
Table view — daily closes
Q2 · Was anything stolen on-chain?
No justice transactions after July 11
Table view
Q3 · Did capital move?
The public graph shrank by a third — across every client, led by large operators' exits
Channels in gossip on Aug 1 that were gone by the cutoff
By client of either endpoint; the line is the same-length window starting May 1
Client shares barely moved
Public nodes, change Aug 1 → latest
Nodes with at least one public channel
Node capacity, change Aug 1 → latest
BTC in public channels, both endpoints counted
Table view
Q4 · What did it cost?
Force closes cost ~6× a cooperative close — in sats, not bitcoins
Q5 · What decides the blast radius?
For the rest of the network it was a bad two days, half the toll of the Tor outage — the nodes that went dark were not hubs
The outage against ordinary churn
One hub against a whole client
Do minority clients depend on LND?
Method & limits
How we measured it
# Reproduce (requires the Bitcoin Data Labs data lake)
python run.py # → data/processed/*.json
python run.py --refresh-labels # after client-inference rule changes