Eclair Patches Lightning Vulnerabilities Guarding Against Excessive Mining Fee Losses

Eclair, the Lightning node software developed by ACINQ, has integrated two corrections for vulnerabilities that could cause a node to lose Bitcoin through inflated mining fees during channel funding and splicing. One update restricts a peer’s fee-increase requests when Eclair contributes capital, while the other validates transactions originating from a compromised Bitcoin backend when Eclair retains the signing keys.

Both fixes landed in the project’s master branch on October 2 and October 5. As of October 12, the release page still listed September’s v0.14.3 as the latest version, meaning these October corrections postdate the current packaged release.

Bitcoin Optech flagged both changes in its October 9 newsletter, describing them as closures for protection gaps existing during dual funding and splicing.

Retaining Keys Alone Is Not Sufficient Defense

PR #3388 concerns peer-initiated replace-by-fee, or RBF, attempts during a dual-funded channel opening or a splice that adjusts a channel’s funding. A peer could request a replacement transaction with a higher fee rate. Eclair historically kept its wallet contribution and paid for its inputs at that rate, without an upper bound or fee budget on this path.

This allowed a malicious peer to impose an arbitrary mining fee rate on the contributing node while contributing nothing itself. The resulting loss would be paid as fees to miners rather than transferred directly to the attacker.

The patch rejects requests exceeding the maximum funding fee rate Eclair recommends to its peers. Two exceptions remain: if the peer buys liquidity and pays the fees for Eclair’s inputs, or if the Eclair node contributes no funds to the transaction, Eclair does not bear the cost addressed by this limit.

PR #3390 addresses a separate threat in Eclair-signer mode. In this setup, Bitcoin Core’s backend, bitcoind, selects coins and builds transactions, while Eclair retains the keys and signs.

A compromised backend could report a fee within budget while constructing a transaction that actually paid more, including by dropping the change output. Under Bitcoin’s transaction accounting, input value not assigned to outputs becomes a miner fee. Missing change can therefore spend funds without paying an attacker’s address.

When a fee budget is supplied, the repair calculates the actual fee from the amounts of the coins being spent, fetched by transaction ID to authenticate their values. It checks that the backend’s reported fee matches and applies the budget to the actual fee. It also checks that Eclair’s rebuilt contributions pay the same verified fee and rejects invalid change-output positions.

These are distinct from the cooperative-closing fee flaw covered in CryptoSlate’s September report and the restart denial-of-service issues covered on October 2.

These repairs address Eclair’s dual-funding, splicing, and signer configurations. Operators should check that their installed build contains the October changes.

Source link