PaperlayerView exact revision on arXiv

Source-linked AI summary

Does Client Diversity Protect the Lightning Network? Evidence from the 2026 Core Lightning Shutdown

Saurabh Kumar

arXiv:2610.20952v2cs.CR

TL;DR

The paper asks whether client diversity protects Lightning despite LND’s concentrated share and the lack of observed client-correlated failures. It measures a real CLN shutdown and calibrates failure scenarios, finding that the outage was largely contained outside the CLN cohort. Its conclusion is that connectivity risk depends on which software the hubs run, not simply how many nodes use each client.

  • Problem

    Client diversity is invoked as protection against implementation bugs, but LND’s large public-network share and the lack of observed client-correlated failures leave its protective value uncertain.

    Source: §I · p. 1

  • Method

    The study measures the 2026 CLN shutdown using daily public-graph gossip and channel-close data, then calibrates client-correlated failure scenarios.

    Source: §I · p. 1, §III · p. 2

  • Results

    About a fifth of CLN nodes went offline, while network-wide reachability loss was about that of an unusual ordinary two-day period and half the loss of the July Tor denial-of-service wave.

    Source: §VIII · p. 8, §XI · p. 10

  • Takeaways & Limitations

    The blast radius of a correlated failure depends on whether it overlaps with hubs, so node-count diversity alone can mislead.

    Source: §VIII · p. 8, §XI · p. 10

    The analysis covers one node’s view of the announced graph, omits unannounced channels, and models static connectivity rather than payment success with private channel balances.

    Source: §IX · pp. 9–10

Abstract

from arXiv · show

Client diversity is often cited as the Lightning Network's defence against a bug in any one implementation, yet LND runs 80% of public nodes (84% counting one operator's fleet of about 2,000 tiny nodes) and holds 84% of public channel capacity, a capacity share that has barely moved since 2023. We test what diversity buys with a natural experiment. On 26 August 2026, amid security fixes in every implementation, Core Lightning (CLN) maintainers told operators who could not upgrade to disconnect their nodes. Using 805 daily gossip snapshots, 132,360 on-chain channel closes and a client classifier validated against self-identifying aliases and against the wallet that builds each node's funding transactions, we find that 22% of CLN nodes went dark overnight, ten times the usual rate, mostly Tor-reachable ones; a third were still dark five weeks later. The rest of the network barely noticed. Reachability among all node pairs fell by 7.8 percentage points, a loss exceeded in 4 of 94 ordinary two-day windows and half that of a Tor denial-of-service wave in July, while among CLN pairs it fell by 24.5 points, more than in any ordinary window. Calibrated failure scenarios explain the containment: the blast radius depends on whether a failure reaches the hubs, not on how many nodes run the failing software. Losing ACINQ's Eclair node alone costs the surviving network four times the reachability lost with all 619 routable CLN nodes, and minority clients' reliance on LND for connectivity is what their size implies; CLN nodes in fact peer with each other more than chance. Diversity statistics that count nodes mislead; the quantity to track is which software the hubs run.

I. INTRODUCTION

The paper asks whether client diversity protects the Lightning Network despite LND’s sustained concentration, a question prior topology studies could not answer from observed client-correlated failures. It uses the 2026 CLN shutdown to measure real-world effects and calibrate failure scenarios.

I. INTRODUCTION

  • Prior topology studies removed random or highly connected nodes, but no study had observed a failure conditioned on implementation.On 26 August 2026, CLN maintainers told operators unable to upgrade to disconnect, creating a natural experiment.Source: §I · p. 1
  • The CLN shutdown hurt its own users, while network-wide reachability loss was comparable to an unusual ordinary two-day period.The complying nodes were mostly peripheral and Tor-reachable; the paper argues that a failure’s blast radius depends on whether it reaches hubs.Source: §I · p. 1
  • The client classifier uses historical feature-bit rules checked against 795 self-identifying aliases and an independent funding-wallet signal.The wallet signal comes from the software that builds channel funding transactions.Source: §I · p. 1
  • LND held 84%–90% of public capacity from May 2023 to October 2026, while its node share fell by five to seven points from late 2024.One operator’s fleet of small LND nodes hides part of the decline in raw node counts.Source: §I · p. 1
  • The study measures the shutdown against churn baselines and a control client, then compares it with transport failures and single-operator closing waves.Its calibrated scenarios and null model assess whether client-correlated failures stay contained and whether hubs, rather than cohorts, carry the risk.Source: §I · pp. 1–2

II. BACKGROUND AND RELATED WORK

The background explains how Lightning gossip and on-chain closes expose outages and channel exits, and reviews prior work on network resilience and client inference. It distinguishes Lightning’s node-availability risk from blockchain consensus failures.

II. BACKGROUND AND RELATED WORK

  • A node outage appears in gossip when peers disable their channel directions toward the unreachable node.A channel close spends its 2-of-2 funding output cooperatively or through a unilateral force close, which can be identified from transaction details.Source: §II · p. 2
  • Prior topology studies found Lightning robust to random failures but fragile to targeted removal of central nodes; none conditioned failure on implementation or observed one.Other work documented centralisation and the fragmentation caused by hub removal.Source: §II · p. 2
  • Prior client-inference methods use channel-policy defaults, announcement values, feature bits, or encrypted traffic metadata; this study validates feature-bit inference against an on-chain signal.Its rules are kept valid across three years of feature-set changes.Source: §II · p. 2
  • Unlike consensus-client bugs that can split a blockchain, a Lightning client failure takes nodes offline, so its cost depends on their positions in the payment graph.The cited discussion notes that independently built implementations can share vulnerabilities, while diversity can multiply distinct attacks.Source: §II · p. 2

III. DATA AND VANTAGE POINT

The study combines daily views of the announced Lightning graph with on-chain channel-close and funding-transaction data. Its graph record is a single node’s view, with a mid-2024 vantage change and incomplete coverage that constrain comparisons.

III. DATA AND VANTAGE POINT

  • The dataset contains 805 usable daily gossip snapshots from 8 May 2023 through 4 October 2026, after excluding partial or stale dumps.The snapshots cover 65% of calendar days; daily coverage is complete enough from May 2026 for the shutdown analysis.Source: §III · p. 2
  • The gossip series is one LND node’s view of the public announced graph; unannounced channels are not visible.The vantage changed in mid-2024, so the study compares levels only within each vantage epoch; 51 partial dumps and one stale day were excluded.Source: §III · p. 2
  • On-chain scanning records 132,360 channel closes and 112,837 spends of force-close outputs from channels in the gossip catalogue.The close records include transaction, block time, and close type; the data also record the types of force-close output spends.Source: §III · p. 2
  • Funding-transaction records capture wallet construction choices for 226,134 channel funding transactions.Recorded choices include nVersion, nLockTime policy, input nSequence, script types, output ordering, signature grinding, and fee rate.Source: §III · p. 2

IV. CLIENT INFERENCE AND VALIDATION

The paper classifies clients mainly from announcement feature bits, with lower-confidence fallbacks, and checks its rules against aliases and funding-wallet behavior. Historical defaults matter because implementation features changed over time.

IV. CLIENT INFERENCE AND VALIDATION

  • Ordered feature-bit rules classify most nodes, while fallback clues such as default colour, alias, and modal CLTV delta yield low or medium confidence.Table I specifies the ordered rules and identifies announcement feature bits and modal CLTV expiry delta as inputs.Source: §IV · p. 2, Table I · p. 3
  • Historical checks are necessary because Eclair’s feature bits changed and CLN operators can disable keysend, making earlier rules unreliable.An earlier rule mislabeled ACINQ as CLN before Eclair added bits 37 and 61.Source: §IV · p. 3
  • The funding-wallet signal separates LND from other clients but cannot distinguish CLN from Eclair or identify LDK.The signal measures the funder’s wallet rather than the daemon, and external-wallet use can make an LND operator appear Core-style.Source: §IV · p. 3
  • On the same held-out folds, rules reach macro-F1 0.93 versus 0.92 for k-NN; wallet-family agreement is 99% for LND-only-bit labels (n = 3,207) and 98% for the CLN set (n = 476).CLTV-only fallbacks are weakest, at 84–95%.Source: Table II · p. 3, §IV · p. 3

V. CONCENTRATION, 2023–2026

LND remained dominant in public capacity from 2023 to 2026, while its node share fell; a managed fleet of small nodes obscures part of that decline.

V. CONCENTRATION, 2023–2026

  • LND held 84%–90% of public capacity from May 2023 to October 2026, while its node share fell from 91.8% to 84.2%.Within the second measurement epoch, the raw node share was nearly flat, but excluding the managed fleet it declined to 80.3% by October 2026.Source: §V · pp. 3–4
  • Figure 1 compares implementation-naming aliases with rule labels and shows wallet-label agreement by rule tier for tiers with at least 10 nodes.Source: Figure 1 · p. 4
  • A managed fleet of 1,972 small LND nodes represented a fifth of public nodes but held only 0.02% of capacity.Without the fleet, LND had 80.1% of nodes and 84.4% of capacity; CLN had 8.5% of nodes and 3.7% of capacity.Source: §V · p. 4

VI. THE 2026 SECURITY WAVE AND THE CLN SHUTDOWN

The CLN shutdown call was followed by a sharp, client-specific outage, while other clients showed little change. The event coincided with broader network contraction and increased organic CLN-related force closes, but the data do not identify who initiated closes.

VI. THE 2026 SECURITY WAVE AND THE CLN SHUTDOWN

  • 22.0% of CLN nodes went dark overnight, about ten times the usual rate, while LND’s 6.4% rate stayed within its ordinary range.The CLN nodes held 33% of CLN capacity; the disabled share toward CLN nodes rose from 11.8% to 38.1% by channel directions and from 7.4% to 35.2% by capacity.Source: §VI · pp. 4–5, Table IV · p. 5
  • 28% of Tor-only CLN nodes went dark, compared with 21% of dual-stack and 7% of clearnet-only nodes; Tor-only LND nodes did not move.The authors say a Tor outage does not explain the CLN change; they suggest, without confirmation, that home and node-in-a-box operators followed the call while hosted operators upgraded.Source: §VI · p. 5
  • During the July Tor denial-of-service wave, disabled shares toward Tor-only nodes of every client rose from 23.7% to 43.5%, while clearnet-only nodes stayed flat.The figure tracks disabled shares by channel count and capacity across July–October, with vertical lines marking events.Source: §VI · pp. 5–6, Figure 4 · p. 6, Figure 3 · p. 6
  • By 4 October, 22% of CLN nodes had never reappeared and 32% were dark, including nodes that had returned and gone dark again.Among returning nodes, the median time dark was three days; most returned shortly after CLN 26.06.7 shipped.Source: §VI · p. 6, Figure 5 · p. 6
  • Organic force closes involving CLN nodes ran at 2.2 times their July–August rate during the two weeks after the call, but the data cannot identify which party broadcast a close.Channels of CLN nodes that went dark were force-closed at 70 per thousand, versus 43 per thousand for CLN nodes that stayed up.Source: §VI · pp. 6–7, Table V · p. 7
  • From 1 August to 4 October, 38% of public channels disappeared, with similar disappearance rates across client cohorts; exits by large operators accounted for much of the contraction.79% of closes were cooperative, and ten operators were party to 31% of them.Source: §VI · p. 7
  • The median force close cost 1,222 sat in fees, six times a cooperative close; the episode’s on-chain cost was negligible compared with locked liquidity and lost channels.All 8,787 force closes paid 0.17 BTC in total.Source: §VI · p. 7

VII. WHAT DECIDES THE BLAST RADIUS

The analysis compares the observed shutdown footprint with ordinary two-day windows and calibrated failure scenarios. It finds that reachability costs depend more on which hubs fail than on the size of a client cohort.

VII. WHAT DECIDES THE BLAST RADIUS

  • The model treats failures as a fraction of a client’s nodes becoming unavailable and measures connectivity under static capacity thresholds, an upper bound on payment success.It uses the 25 August routable core; channel balances and liquidity uncertainty are not modeled.Source: §VII · p. 7
  • The shutdown reduced reachability for 100k-sat payments by 7.8 points across all node pairs and 24.5 points among CLN pairs.Four of 94 ordinary windows exceeded the all-pairs loss, while no ordinary window exceeded the CLN-pair loss; the two Tor-event windows cost the whole network 15.6–16.0 points.Source: §VII · p. 7, Figure 6 · p. 8
  • With 22% of CLN nodes failing at random, reachability among survivors was 78.8%, similar to 78.2% when the same number failed across all clients.Losing all 619 CLN core nodes left survivors at 76.2%; losing the 11 Eclair core nodes left 63.9%.Source: §VII · p. 7
  • ACINQ’s Eclair node alone cut survivor reachability by 15.9 points, four times the 3.7-point loss from all 619 CLN nodes.Criticality followed a node’s role in connecting others, not simply its capacity; nodes serving as the only adequate link for many small nodes mattered greatly.Source: §VII · pp. 7–8
  • Minority clients’ channel capacity faced LND, but CLN placed 15% of its capacity on CLN peers versus 8% under the capacity-matched null model.Without LND, 32% of CLN pairs remained connected versus 9% under the null model; Eclair and LDK observed values fell within their null ranges.Source: §VII · p. 8

VIII. DISCUSSION

The CLN shutdown’s network-wide reachability loss was comparable to an unusual ordinary two-day period, while its impact was concentrated among CLN users. The discussion argues that correlated-failure risk depends on whether failed software is run by hubs, and draws operational lessons from the outage.

VIII. DISCUSSION

  • The network absorbed the first measured clientwide outage, while the affected cohort lost a third of its internal reachability and saw organic force closes double.The network-wide loss was about as large as an unusual ordinary two days and half the loss in the Tor denial-of-service wave a month earlier.Source: §VIII · p. 8
  • A correlated failure’s blast radius depends on overlap with hubs: ACINQ alone outweighs the entire CLN cohort for surviving-network reachability.The discussion says node-count diversity can mislead because connectivity is concentrated in a few operators.Source: §VIII · p. 8
  • Compliance was voluntary and uneven: 22% of CLN nodes, mostly Tor-reachable, went dark, and a third remained dark after five weeks.The paper advises --offline rather than shutdown because an offline node continues watching the chain for revoked states and expiring HTLCs.Source: §VIII · pp. 8–9
  • The authors recommend monitoring peer-side disabled shares, measuring diversity by hub capacity or reachability, and encouraging channels between minority-client hubs.They also recommend version- and duration-scoped emergency guidance and preferring --offline to shutdown.Source: §VIII · p. 9

IX. LIMITATIONS

The study measures the announced graph from one node’s view, so unannounced channels and some client usage are invisible. Its connectivity model uses static capacity thresholds and does not model liquidity depletion or other payment constraints, making absolute reachability an upper bound on payment success.

IX. LIMITATIONS

  • Gossip captures one node’s view of the announced graph, which changed in mid-2024 and has gaps before 2026.Unannounced channels, including most LDK and Phoenix usage, are invisible, and users reach the network through providers’ nodes.Source: §IX · p. 9
  • Client inference and outage measurements have scope limits: feature-bit rules can fail for new releases, and disabled flags reflect peers’ views with delay.The on-chain signal identifies wallets rather than daemons and cannot distinguish CLN from Eclair or identify LDK.Source: §IX · pp. 9–10
  • The static-capacity resilience model is an upper bound on payment success because it omits private balances, rerouting-related liquidity depletion, fees, HTLC limits, and private routing hints.The paper says absolute reachability therefore overstates payment outcomes, while comparisons use the same model.Source: §IX · p. 10

X. ETHICS

The study uses public gossip and blockchain data, reports aggregates, and avoids publishing lists of potentially vulnerable nodes.

X. ETHICS

  • The authors report aggregates and publish no lists of potentially vulnerable nodes, naming large public operators only for public closing behavior or ACINQ’s widely known hub role.Their analysis uses public gossip and blockchain data.Source: §X · p. 10

XI. CONCLUSION

The conclusion emphasizes that LND’s capacity share has remained high while the CLN shutdown was contained. It argues that diversity protects the network insofar as it reaches the hubs.

X. CONCLUSION

  • LND holds about 85% of public Lightning capacity, a share that has barely moved in three years.When an emergency took a fifth of CLN nodes offline, the network absorbed it; the damage stayed within the CLN cohort.Source: §XI · p. 10
  • Client diversity protects the Lightning Network to the extent that it reaches the hubs.Source: §XI · p. 10
Loading 2610.20952v2…