Eclair tightens Bitcoin funding rules after unconfirmed inputs put Lightning payments at risk
The October 27 release requires confirmed peer inputs for splices by default and improves recovery when a channel must close with funding still pending. Read the full story on CryptoSlateUnderstand the crypto stories that matter and what to watch next. Get The Catalyst in your inbox
Bitcoin Lightning developer ACINQ has urged node operators to upgrade after fixing security weaknesses that malicious peers could exploit.
The company released Eclair version 0.14.6 on Oct. 27, introducing stricter transaction requirements and recovery mechanisms to prevent manipulated channel funding from jeopardizing pending payments.
“We highly recommend upgrading, as some of these issues can be exploited by malicious nodes,” ACINQ said in its release announcement.
The warning centers on a weakness in how Lightning channels handle funding changes before the underlying Bitcoin transactions are confirmed.
Lightning allows users to transfer Bitcoin through payment channels without recording every transaction on the blockchain. Operators can also add or withdraw liquidity from existing channels through a process known as splicing.
However, ACINQ's release documentation warns that accepting unconfirmed funding inputs from another node creates an opportunity for manipulation.
A malicious peer could double-spend an unconfirmed transaction after signing a splice, invalidating the funding arrangement that supports the channel.
If the affected channel subsequently closes through Bitcoin's blockchain, pending payments secured by conditional contracts known as HTLCs could become vulnerable because their settlement depends on the invalidated funding transaction.
Related ReadingThe developers described a potential security exposure rather than a confirmed theft, leaving the extent of any real-world exploitation unknown.
The update introduces a new security setting that requires confirmed inputs from peers before they can contribute funds to channel splices.
Enabled by default, the protection also prevents operators from building additional splices on top of unconfirmed funding changes, reducing opportunities for malicious peers to undermine settlement.