The Zero-Cost Attack: Eclair's Unfunded Channel DoS and the Concentration Risk Beneath Lightning

Contrary to the prevailing assumption that griefing a Lightning node requires capital, Eclair's most recent denial-of-service vulnerability required none. A malicious peer needed a connection to a reachable node and the patience to let a counter run. In a controlled regtest environment, a 4GB JVM heap was exhausted in 47 minutes and 43 seconds. The channel database swelled to 217,623 rows of phantom state—channels never funded, never broadcast, never real. When the operator restarted, the records reloaded, the memory filled again, and the node fell over a second time. The attacker spent zero satoshis on on-chain fees. No funding transaction. No broadcast. No cost. That asymmetry—free to attack, expensive to defend—is the actual story, and it is the part the market walked past. Eclair is not a household name, which is precisely why it matters. Maintained by ACINQ, the Paris-based firm behind the Phoenix wallet, Eclair is one of four production-grade Lightning implementations, alongside LND, Core Lightning, and LDK. It runs in Scala on the JVM. It powers a meaningful slice of public routing capacity. And through the second half of 2025, it became the subject of sustained security scrutiny—first this class of availability bugs, then a separate fund-loss vulnerability patched in version 0.14.3. Production-grade matters here. These are not experimental clients. They settle real payments, route real liquidity, and underwrite real merchant flows. LND, maintained by Lightning Labs, dominates node counts. Core Lightning, backed by Blockstream, anchors the plugin ecosystem. LDK packages Lightning as an embeddable library. Eclair, the Scala outlier, drives Phoenix and a set of public routers. When one of four implementations carries a defect, the network's aggregate reliability is only as strong as its weakest deployed version—and deployments lag patches by months, not days. To understand the defect, you have to understand the channel lifecycle. A Lightning channel begins as a negotiation. Two peers exchange messages, agree on parameters, and produce a temporary channel identifier—before any funding is confirmed. Only when the funding transaction is broadcast and buried on-chain does the channel earn its final, stable identifier. The temporary ID is cheap; it costs nothing but a socket and a few bytes of state. The final ID is expensive; it is anchored to Bitcoin, to real capital, to proof-of-work. Eclair counted channels. It simply did not count them consistently. The implementation imposed a limit on the number of pending channels a single peer could open—that limit was the defense. The defense failed because the check applied to the final channel identifier while the stored request was keyed to the temporary one. A peer could therefore accumulate saved requests without ever tripping the threshold the counter was watching. The counter undercounted. The database over-accumulated. No funding transaction, no on-chain fee, no capital commitment—just a slow, deliberate flood. When I audited cross-chain bridge logic during the 2017 ICO cycle, the same failure pattern recurred: a system holds two identifiers for one logical object, and the enforcement path checks only one. The object then exists in a state the guard cannot see. This is not exotic. It is the most common shape of an accounting bug, and it appears wherever developers optimize for the cheap identifier and forget that the expensive one is what the invariant was written against. Eclair optimized for the temp ID. The invariant was written against the final ID. The gap between them was the attack surface. That is the mechanism. The consequences are worse. And the consequences compound, because a flaw that survives restart does not announce itself—it metastasizes. Two distinct findings emerged from the disclosure. The first, attributed to independent researcher Erick Cestari, is a persistent database flood. Its defining property is that it survives restart. The poisoned records sit on disk; a reboot reloads them; the exhaustion recurs. This is not a transient spike. It is a standing condition. The second, catalogued as LNF-2026-0003 by Matt Morehouse of lnfuzz, is a channel-open race condition that spawns orphaned processes consuming memory and CPU—annoying, but recoverable by disconnecting or restarting. The distinction is not academic. One bug is a heart attack. The other is a sprained ankle. Operators who treat them as a single event will misjudge the threat model and, more importantly, misjudge which nodes are actually recoverable. The economics are the most instructive layer. Lightning's usual attack surface requires capital: to grief a channel, you generally fund it, and funding costs Bitcoin. This vulnerability inverted the equation. The attacker's cost curve—compute and bandwidth—is trivially low. The victim's cost curve—heap exhaustion, database bloat, manual cleanup or forced memory increases—is high and recurring. When I modeled similar asymmetries during the 2020 DeFi Summer, the pattern was invariant: any system where defense is expensive and offense is free is a system that eventually gets tested. Eclair got tested. Now the targeting. The exploit requires the victim node to be reachable—public, routable, listening. That is not incidental. It is a selection filter. Private nodes, mobile wallets behind NAT, the bulk of Phoenix's user base—none of these are the objective. The objective is the routing layer itself. If you wanted to degrade Lightning's reliability without touching Bitcoin's monetary layer, you would attack precisely the nodes this bug attacks. Reachability deserves a harder look, because it reframes the entire threat. A reachable node advertises itself; it is the connective tissue that turns isolated channels into a network. If the exploit's precondition is reachability, then the vulnerability's true target is not a wallet or a user—it is the topology. Coordinated abuse of this bug against a cluster of well-connected routers would not steal funds. It would thin the graph. And a thinner graph means higher routing failure rates, longer payment paths, and a measurable decline in the reliability that Lightning's entire value proposition rests on. Then there is the timeline, which deserves its own dissection. PR #3324 merged on July 17. Version 0.14.1 shipped on July 29. Public disclosure arrived on September 30. That is a two-month silent-patch window. Throughout it, the diff was public, the fix was reversible, and anyone monitoring the repository could have reverse-engineered the exploit. Coordinated disclosure is a ritual, not a guarantee. The window between patch and disclosure is where the real risk lives, and it is almost never discussed. The final nuance is the recommendation itself. ACINQ did not tell operators to upgrade to 0.14.1. It told them to upgrade to 0.14.3. That gap is not cosmetic. Between 0.14.1 and 0.14.3 sits a separate fund-loss vulnerability, patched September 14 and disclosed September 21. An operator who read the DoS advisory, upgraded to 0.14.1, and stopped there would have sealed the availability hole while leaving the money hole wide open. This is the kind of layered failure that only becomes visible when you read version numbers as a sequence rather than a footnote. The fix itself is instructive. PR #3324 tightened duplicate-channel checks—a targeted correction, not a redesign. That is appropriate for a patch, but it leaves the underlying design question open: why did the pending-channel limit key on the final identifier in the first place? A more robust architecture would enforce the cap against every channel state, funded or not, and would treat temp-ID accumulation as a first-class resource to be bounded independently. Whether that redesign follows is the real measure of whether the lesson was learned or merely patched around. Read the sequence closely and it tells you something about the codebase. DoS in July. DoS again, plus a race condition. Fund loss in September. Three classes of defect, surfaced within roughly ninety days, by independent researchers and a specialized fuzzing outfit. That cadence does not look like an isolated typo. It looks like a project undergoing concentrated security review—either because scrutiny increased, or because the code carried accumulated debt that scrutiny finally reached. Both explanations point the same direction. The involvement of lnfuzz is itself a signal. Specialized fuzzing of Lightning implementations is a recent discipline, and its output is predictable: a steady drip of findings, each individually minor, collectively a map of accumulated technical debt. A codebase under sustained fuzzing does not become safe. It becomes instrumented. The absence of disclosures is not evidence of security; it is evidence that no one is looking. Eclair is being looked at. That is uncomfortable and necessary in equal measure. The operational reality is messier than any advisory. A node operator running 0.14.0 does not necessarily know they are exposed until the node stops responding—and if the persistent flood is the cause, restarting will not tell them anything except that the problem repeats. Diagnosing a restart-ineffective failure requires reading logs most operators never open, correlating database growth with heap pressure, and recognizing that the standard first response is the wrong one. This is the gap between a patched vulnerability and a remediated one, and it is where most real-world damage happens. The contrarian read is that this is an Eclair problem—one implementation, one bug class, now patched, irrelevant to Bitcoin, irrelevant to price. That reading is technically correct and strategically blind. Eclair is not a peripheral player. It is maintained by ACINQ, the same entity that operates Phoenix, a consumer wallet. Implementation and wallet under one roof. When the implementation wobbles, the downstream wallet inherits the blast radius. Compare that to LND's multi-stakeholder ecosystem or Core Lightning's Blockstream-adjacent plurality, and the concentration becomes visible. Decentralization is not a property of a protocol. It is a property of who maintains the code that runs it. Lightning's protocol specification is decentralized. Its implementations are not. Four teams, and the failure of one degrades a shared layer for everyone routing through it. The unfunded-channel bug did not touch a single satoshi of Bitcoin's issuance or ledger integrity. What it touched was the layer above: the availability of a routing network that Bitcoin's scaling narrative depends on. The market, correctly, assigned near-zero price impact. That is exactly the problem. Price is not the only signal, and no price impact is not the same as no systemic impact. There is a deeper point about market signaling. Bitcoin's price is a function of monetary policy, liquidity cycles, and institutional flow—not of a Scala implementation's memory management. So the null price reaction was correct. But markets price assets, not infrastructure, and infrastructure failures surface later as reliability decay. The institutional absorption studies I ran after the 2024 ETF approvals taught me that the most important data rarely shows up in the price first. It shows up in the plumbing. Here, the plumbing is the routing layer, and the plumbing sprung a leak. For operators, the prescriptive path is narrow. Upgrade to 0.14.3, not 0.14.1. Increase JVM heap only after clearing phantom channel records, because a larger heap merely delays the flood. Treat restart-ineffective bugs as a distinct operational category, since standard remediation—reboot and hope—actively fails here. And monitor the repository diff window, because the two months between patch and disclosure are the two months an unpatched node is most exposed. The question is not whether Eclair is safe. It is not. Nothing reachable is. The question is whether a network that routes real value through four implementations, one of which carries a single-maintainer concentration and a proven restart-ineffective failure mode, has actually priced its own fragility. The market says yes. The 217,623 rows of phantom channel state say otherwise.