Eclair patches two denial-of-service vulnerabilities in channel opening
Eclair, the Lightning Network implementation maintained by ACINQ, released v0.14.1 in July to patch two denial-of-service vulnerabilities in its channel opening logic that could drain a node’s memory and force crashes. Both flaws bypassed safety checks that were supposed to limit the number of concurrent channel setup attempts, allowing attackers to spawn hundreds of pending channels with no onchain expense.
- Race condition in temporary_channel_id check let attackers create duplicate channel states, leaking 1 MB of memory per second.
- Second flaw reused channel IDs to bypass pending-channel limits, exhausting 4 GB of memory in 48 minutes per test.
- Mobile wallets using Eclair as a Lightning Service Provider were unaffected because ACINQ had patched its own LSP software earlier.
Erick Cestari disclosed the vulnerabilities to Delving Bitcoin after fixes landed in Eclair #3324, which shipped in v0.14.1 in July. Users running Eclair v0.14.0 or older should upgrade immediately. The first vulnerability, discovered by Matt Morehouse using his smite fuzzer, exploited a race condition in how Eclair validated temporary channel IDs during the channel opening handshake.
Race Condition Leaves Unreachable Channel States
Eclair checked whether a temporary_channel_id was already in use before accepting an open_channel message, but did not record the new channel in its internal state until a later step.
An attacker sending several identical open_channel messages in rapid succession could pass the check multiple times, causing Eclair to create two channel states for a single ID. The second state would overwrite the first, leaving an unreachable channel consuming approximately 25 kB of memory until the peer disconnected.
Repeating the attack leaked about 1 MB per second, forcing nodes to run out of memory or exhaust CPU cycles servicing garbage collection. The attack required no onchain transactions and no valid channel funding.
Pending-Channel Limiter Bypassed via ID Reuse
Cestari found a second flaw in Eclair’s defense against resource exhaustion: a limit on the number of pending channels whose funding transaction had not yet confirmed. The duplicate check only examined temporary IDs, allowing an attacker to start opening a channel, then reuse that channel’s final channel_id as the temporary_channel_id in the next open_channel message.
The counter would count the reused ID twice, then drop both entries when the new channel received its final ID, so the limit never rose above two while pending channels multiplied without bound.
Each pending channel stores a copy of the peer’s init features. An attacker setting a single unknown odd feature bit at a high position inflated each copy to about 65 kB. In Cestari’s test, one connection exhausted a node’s 4 GB of RAM in about 48 minutes.
Because pending channels are written to disk, the node crashed on every restart until memory limits were raised or the database rows deleted manually.
Mobile Wallets and LSP Operators Already Protected
Morehouse noted that mobile wallets using an Eclair node as their Lightning Service Provider, including ACINQ’s Phoenix wallet, were unaffected. ACINQ had patched its own LSP software before public disclosure. Node operators running Eclair v0.14.0 or older on the open network remain vulnerable and should prioritize upgrading to v0.14.1 or later.
Offchain Contract Framework Proposed for Lightning Channels
Adam Gibson posted to the Bitcoin-Dev mailing list a proposal for LN-GAP, a protocol to run complex multi-round, two-party contracts inside Lightning channels while settling disputes onchain in a constant number of transactions. Gibson implemented a chess game as a proof of concept, chosen because games are difficult to enforce onchain efficiently. A winning player takes the entire pot.
The construction introduces a venue, a committee of members who attest whether a signed message was published before a deadline, without handling user funds or holding custody. Gibson avoids FROST-style threshold signatures to keep fraud attributable to individual malicious members.
Instead, attestation uses per-member “one-bit signatures” verified with OP_CHECKSIGADD, and members are paid fees atomically over channels using adaptors.
Lightning can enforce rules about a published state, but it cannot do so in case a counterparty stalls or stops responding.
Adam Gibson, Bitcoin-Dev mailing list
The scheme relies on an honest-majority assumption: if more than half of the venue’s members collude with one party, funds at risk could be stolen. Beyond games, Gibson identifies proof-of-storage contracts and offchain dispute resolution as potential applications.
Multiple Bug Fixes Across Lightning Implementations
Eclair released three additional bug fixes in recent pulls. One prevents a malicious peer from stalling splice transactions by choosing distant absolute locktimes, adding inputs, or setting very low feerates. A second makes Eclair retry commitment and penalty transactions rejected by conflicting unconfirmed transactions, and applies to zero-conf channels.
A third recognizes when an RBF replacement of a splice confirms after Eclair force-closes, preventing funds from remaining locked.
LDK released two fixes: one corrects payment hash reuse that could cause the implementation to fulfill the wrong HTLC after a settlement, and another ensures funded payments are only forwarded over the channel where liquidity was purchased.
LDK also fixed a bug where restarting during cooperative channel close could prevent pending HTLCs from failing back to upstream peers, and patched a privacy leak in onion messages over blinded paths where dummy hops accepted message-content TLV records.
LND added a check for auxiliary HTLC signatures on experimental Taproot overlay channels for Taproot Assets. Rust Bitcoin introduced a ScriptCode type to prevent callers from incorrectly hashing complete scripts during signature verification for legacy and segwit v0 inputs.
BDK fixed a bug where an Electrum-backed wallet could lose track of transaction confirmations after a reorg if the transaction was mined again at the same height.
The CCS read. The Eclair vulnerabilities underscore why Lightning implementations must not only check preconditions at entry but also hold state atomically. Both flaws relied on separating validation from state recording, a pattern that will recur as Lightning channels grow more complex. The LN-GAP proposal imports dispute resolution onto a cheaper layer but outsources timeliness to a committee; builders need to understand the venue’s incentive structure before deploying in production.
Eclair users running v0.14.0 or earlier should verify they are running v0.14.1 or later. Gibson’s LN-GAP repository and paper are live; the next concrete event is whether any Lightning Service Provider or wallet integrates the framework into a testnet deployment.
