CryptoSlate
Eclair, ACINQ's Lightning node implementation, has merged two repairs for flaws that could cost a node Bitcoin through excessive mining fees. The first, PR #3388, caps peer-initiated replace-by-fee demands during dual-funded channel opens and splices: previously, a malicious peer could impose an arbitrary fee rate on transactions carrying Eclair's own wallet contribution, with the loss paid to miners rather than to the attacker. The second, PR #3390, targets Eclair-signer mode, where bitcoind builds transactions while Eclair holds the keys. A compromised backend could report a fee within budget while constructing a transaction that actually paid more, for example by dropping the change output, since under Bitcoin's transaction accounting any unassigned input value becomes a miner fee.
Why it matters
Both gaps exploited legitimate protocol mechanics rather than a single bug, which makes them hard to spot: in one case the node knowingly pays a peer-nominated fee rate, in the other the fee figure it checks is simply a lie. Bitcoin Optech's Oct. 9 newsletter flagged both changes as closing protection gaps in dual funding and splicing configurations. These are distinct from September's cooperative-closing fee flaw and the Oct. 2 restart denial-of-service issues.
Market impact
The repairs merged into master on Oct. 2 and Oct. 5, but as of Oct. 12 the project's release page still listed September's v0.14.3 as the latest packaged build, so the October fixes postdate it. Eclair operators should verify their installed build contains the October changes, especially on dual-funding, splicing or signer setups.
No loss events are reported; the fixes are preventive. The practical action item is build verification, since running master-branch code or waiting for the next tagged release is the only way to get the protections today.
Frequently asked questions
-
What flaws were fixed in Eclair's Lightning software?
Two fee-drain vulnerabilities: an unbounded replace-by-fee path during dual-funded channel opens and splices, and a gap in Eclair-signer mode where a compromised Bitcoin Core backend could build transactions paying more than its reported fee.
-
How could a malicious peer steal from an Eclair node via fees?
During a dual-funded channel opening or splice, the peer could request a replacement transaction at an arbitrary fee rate, and Eclair paid its own wallet contribution at that rate with no upper bound. The loss went to miners as fees rather than to the attacker.
-
What is the Eclair-signer mode flaw (PR #3390)?
bitcoind selects coins and builds transactions while Eclair retains the signing keys. A compromised backend could report a fee within budget while constructing a transaction that actually paid more, including by dropping the change output, since unassigned input value becomes a miner fee under Bitcoin's transaction…
-
Which Eclair release contains the October fee fixes?
As of Oct. 12 the fixes existed only in the master branch, merged on Oct. 2 and Oct. 5. The latest packaged release, September's v0.14.3, predates both repairs, so operators should verify their installed build contains the October changes.
-
Were any Eclair nodes actually drained by these flaws?
No loss events are reported. Bitcoin Optech's Oct. 9 newsletter highlighted both changes as closing protection gaps, and the fixes are preventive rather than a response to a known exploit.
WuBlockchain
WatcherGuru
TheBlock
CoinDesk
Crypto News