Eclair has merged two fixes aimed at preventing Lightning nodes from paying excessive Bitcoin miner fees during channel funding and splicing. The changes entered the project’s main branch on October 2 and October 5. As of October 12, however, Eclair’s release page still listed September’s v0.14.3 as the latest version, so the fixes are not confirmed as part of a released build.
Developed by ACINQ, Eclair is Lightning node software. The fixes address fees in dual-funded channels and channel splicing, as well as transaction checks in Eclair-signer mode. Any resulting loss would be paid as a miner fee, rather than transferred directly to an attacker.
PR #3388 caps counterparty-driven fee increases
The first fix, PR #3388, addresses replacement-by-fee (RBF) transactions initiated by a counterparty. When opening a dual-funded channel or changing channel funding through splicing, a counterparty can propose a replacement transaction with a higher fee rate. Before the fix, an Eclair node contributing funds could end up paying more for its share of the transaction, with no explicit fee cap or budget in this process.
A malicious counterparty could therefore push a funding Eclair node to accept an arbitrarily high miner-fee rate without contributing to that additional cost. The node’s loss would go to miners as a transaction fee, not directly to the counterparty.
Under the fix, Eclair rejects requests that exceed the fee-rate limit it recommended for the funding transaction. The restriction does not apply when the counterparty pays for liquidity and covers Eclair’s contribution fee, or when the Eclair node does not contribute to the transaction. In those cases, the node does not bear the fee cost targeted by the fix.
PR #3390 checks actual fees in signer mode
The second fix, PR #3390, concerns Eclair-signer mode. In this setup, the Bitcoin Core backend, bitcoind, selects the bitcoin and constructs the transaction, while Eclair retains the private keys and signs it. Keeping the signing keys does not by itself protect against a compromised backend: it could report a fee within budget while constructing a transaction that pays more, for example by removing a change output to increase the miner fee.
In Bitcoin transactions, any input value not assigned to an output becomes the miner fee. Removing change can therefore cost the node money without sending those funds to an address controlled by an attacker.
The fix calculates the actual fee from the value of the inputs being spent and retrieves the relevant transactions by transaction ID to verify those amounts. Eclair then compares the backend’s reported fee with the calculated fee and applies the budget to the actual amount, rather than relying only on the backend’s figure. It also checks that the funding portion Eclair reconstructs pays the same verified fee and rejects transactions with an invalid change-output position.
October fixes are not yet listed in a release
The two changes address fee limits for dual funding and splicing, and transaction-fee verification in signer mode. They are separate from an earlier vulnerability involving fees for cooperative channel closures and from the denial-of-service issue disclosed on October 2, which could affect nodes after a restart.
As of October 12, Eclair’s release page continued to show v0.14.3, released in September, as the latest version. Merges into the main branch do not confirm that the fixes are available in a packaged release. Node operators will need to check whether their installed build includes the October changes.