Eclair merges fixes for Lightning flaws that could burn Bitcoin in fees

ACINQ’s Lightning node software, Eclair, has integrated two patches to address vulnerabilities that could drain a node’s Bitcoin via excessive mining fees during splicing and channel funding operations. One patch restricts a peer’s fee-bump demands when Eclair supplies funds, whereas the other validates transactions originating from a compromised Bitcoin backend while the signing keys remain under Eclair’s control.

The project’s master branch incorporated these fixes on Oct. 2 and Oct. 5. As of Oct. 12, the release page continued to show September’s v0.14.3 as the most recent version, meaning both October updates arrived after that packaged release.

The Bitcoin Optech newsletter dated Oct. 9 spotlighted both updates for closing protection gaps that emerge during splicing and dual funding.

The initial patch, designated PR #3388, targets peer-led replace-by-fee (RBF) requests that occur during a splice to adjust an existing channel or a dual-funded channel setup. A peer could demand a replacement transaction sporting a heightened fee rate. Previously, Eclair contributed to its wallet and paid for its inputs at that exact rate without enforcing an upper limit or a fee budget.

Consequently, a malicious peer could force an arbitrary mining fee rate onto the contributing node without contributing any funds of its own. Rather than going to the peer, the lost funds would end up as miner fees.

To counter this, the repair blocks any requests exceeding the maximum funding fee rate that Eclair suggests to its peer. Two exceptions apply: if the peer purchases liquidity and covers the fees for Eclair’s inputs, or if the Eclair node contributes zero funds to the transaction. Eclair avoids the costs targeted by this limit under these specific scenarios.

Keeping keys is only part of the defense

PR #3390 tackles an entirely separate security risk tied to Eclair-signer mode. In this setup, bitcoind (the Bitcoin Core backend) selects coins and builds transactions, while Eclair keeps hold of the keys and handles the signing process.

If the backend were compromised, it could report an acceptable fee within budget while simultaneously constructing a transaction that extracts a higher cost, potentially by dropping the change output. Because any input value omitted from outputs counts as a miner fee under Bitcoin transaction accounting, missing change can deplete funds without routing them to an attacker’s address.

When a fee budget is provided, the updated code calculates the true fee based on the spent coins’ values, fetching them by transaction ID for authentication. It verifies that the backend’s claimed fee aligns with this calculation and enforces the budget against the actual fee. Additionally, it confirms that Eclair’s reconstructed contributions adhere to this verified fee and invalidates incorrect change-output placements.

These vulnerabilities are separate from the cooperative-closing fee bug featured in CryptoSlate’s September report, as well as the restart denial-of-service flaws disclosed on Oct. 2.

Because these patches target Eclair’s signer, splicing, and dual-funding configurations, node operators should verify that their running builds incorporate the October updates.

Frequently Asked Questions

• What software does this affect?

  This affects Eclair, which is ACINQ’s Lightning node software.

• What was causing nodes to potentially lose Bitcoin?

  Gaps in dual funding, splicing, and signer configurations could allow excessive mining fees to drain node balances, either through malicious peer fee-bump demands or compromised backend transaction building.

• When were the fixes merged?

  The repairs were merged into the project’s master branch on Oct. 2 and Oct. 5.

• What should node operators do?

  Operators should verify that their installed builds include the October updates.