The Bitcoin Lightning Network development firm ACINQ has issued an urgent advisory for node operators to upgrade their software following the discovery of security vulnerabilities that could allow malicious actors to jeopardize pending payments. The release of Eclair version 0.14.6 on October 27 marks a significant shift in how the implementation handles channel funding, moving toward a more conservative security posture to protect the integrity of the Layer 2 scaling solution. The update specifically addresses weaknesses in the "splicing" mechanism, a feature designed to enhance liquidity management but one that, if left unchecked, provides an opening for transaction manipulation and potential loss of funds.

At the heart of the issue is the way Lightning channels interact with unconfirmed Bitcoin transactions. Under the previous protocol logic, nodes could accept unconfirmed funding inputs from peers when performing a splice—a process that allows users to add or remove funds from an existing channel without needing to close and reopen it. While this allowed for faster liquidity adjustments, ACINQ’s latest documentation reveals that this flexibility created a vector for "double-spending" attacks. A malicious peer could sign a splice transaction using unconfirmed inputs and subsequently broadcast a competing transaction to the Bitcoin mainnet, effectively invalidating the splice and leaving the Lightning channel in a precarious state.

The Mechanics of the Vulnerability

The security exposure identified by ACINQ involves the relationship between the underlying Bitcoin blockchain (Layer 1) and the Lightning payment channel (Layer 2). Lightning operates through a series of pre-signed commitment transactions that represent the current balance of the channel. These transactions are secured by Hashed Time-Locked Contracts (HTLCs), which ensure that payments are either successfully routed or returned to the sender after a certain period.

When a splice occurs, the funding transaction for the channel is updated. If a node accepts unconfirmed inputs for this update, it relies on the assumption that those inputs will eventually be included in a Bitcoin block. However, if a malicious peer double-spends those inputs, the new funding transaction becomes invalid. If the channel is then forced to close—either due to a technical error or a deliberate move by the attacker—the commitment transactions tied to the invalid funding state cannot be settled on-chain. This puts any pending HTLCs at risk, as the settlement logic depends on a valid, confirmed funding anchor.

While the developers at ACINQ have described this as a potential security exposure rather than a confirmed instance of theft, the theoretical risk was deemed high enough to warrant a mandatory shift in the software’s default behavior. The extent of any real-world exploitation remains unknown, but the update aims to close the window of opportunity before such attacks become widespread.

Technical Safeguards in Eclair v0.14.6

The primary fix introduced in the 0.14.6 update is a new security setting that requires confirmed inputs from peers before they can contribute funds to channel splices. This protection is now enabled by default, ensuring that node operators do not inadvertently expose themselves to double-spend risks. By requiring at least one confirmation on the Bitcoin blockchain for any input provided by a peer, Eclair significantly increases the cost and difficulty of executing a manipulation attack.

Furthermore, the update prevents operators from building "chained splices"—additional funding changes layered on top of unconfirmed previous changes. This "depth" of unconfirmed transactions has long been a concern in the Bitcoin ecosystem, as a single failure at the base of the chain can cause all subsequent transactions to collapse. By enforcing a "one-at-a-time" rule for confirmed funding, ACINQ is prioritizing settlement certainty over the speed of liquidity adjustments.

The developers have also refined the software’s settlement logic to handle "force-closes" more gracefully. In scenarios where a channel must be closed while a funding transaction is still pending or has disappeared from the mempool, Eclair will now automatically select a commitment transaction backed by funding that its Bitcoin Core backend recognizes. If necessary, the software will revert to the latest confirmed funding state, ensuring that the node does not attempt to broadcast an invalid transaction that would result in a "stuck" channel or lost HTLCs.

Chronology of the Security Patch and Disclosure

The road to the 0.14.6 release involved a process of responsible disclosure and rigorous testing. The vulnerability was brought to ACINQ’s attention by security researcher Erick Cestari, who has been credited with identifying the edge cases where unconfirmed inputs could lead to settlement failures.

• Early October 2024: Internal audits and reports from the security community identified potential inconsistencies in how Eclair handled unconfirmed parent transactions during splicing operations.
• Mid-October 2024: ACINQ developers began drafting Pull Requests (specifically #3417 and #3419) to overhaul the settlement logic and introduce the "confirmed inputs" requirement.
• October 27, 2024: Eclair version 0.14.6 was officially released. The announcement included a strong recommendation for all node operators to upgrade immediately, citing the exploitability of the previous version by malicious nodes.
• Post-Release: ACINQ clarified that while the update changes default behaviors, existing channels remain compatible and do not need to be closed to facilitate the upgrade.

The release also addressed a secondary issue involving how Eclair tracks transactions that miners confirm after the software has already moved on to a different preferred settlement route. Previously, if a transaction was confirmed late, Eclair might misidentify it as belonging to the counterparty, potentially failing to claim funds that were rightfully the operator’s. The new logic improves the software’s ability to recognize and recover these outputs, adding another layer of financial safety for routing nodes.

Supporting Data and Ecosystem Context

The Lightning Network has seen explosive growth over the last three years, with its total capacity currently hovering around 5,000 BTC. As the network matures, the complexity of its features has increased. Splicing, which was formalized in the Lightning specifications (BOLTs) to solve the "inbound liquidity" problem, is considered one of the most important UX improvements for the network. However, as the Eclair vulnerability demonstrates, complexity often introduces new attack surfaces.

ACINQ is one of the "Big Three" implementations of the Lightning Network, alongside Lightning Labs (LND) and Blockstream (Core Lightning). Their Eclair implementation is particularly popular among enterprise routing nodes and forms the backbone of the Phoenix wallet, one of the most widely used non-custodial Lightning wallets. Because ACINQ’s software is a critical piece of infrastructure, any security flaw in Eclair has the potential to impact a significant percentage of the network’s total liquidity.

The decision to disable unconfirmed inputs by default reflects a broader trend in the Bitcoin development community toward "defensive programming." This shift was accelerated by the discovery of "Replacement Cycling" attacks in late 2023, which also targeted the way Lightning nodes handle mempool transactions. By tightening the rules around funding, ACINQ is signaling that for the Lightning Network to reach institutional-grade reliability, it must prioritize the security of the underlying Bitcoin settlement over the convenience of instant off-chain adjustments.

Official Responses and Recommendations

In their release notes, ACINQ was blunt about the necessity of the update: "We highly recommend upgrading, as some of these issues can be exploited by malicious nodes." The firm also cautioned against the use of the "zero-fee commitment" feature when dealing with untrusted peers. This feature, which allows for more flexible fee management during periods of high on-chain congestion, can be abused if the peer does not have a vested interest in the honest settlement of the channel.

Security researcher Erick Cestari, whose work led to these fixes, emphasized the importance of robust state machine logic in Layer 2 protocols. In the world of Bitcoin, where transactions are immutable once confirmed, the "pre-confirmation" period is a "no man’s land" where developers must account for every possible permutation of transaction replacement and double-spending.

For node operators, the upgrade process is straightforward but requires downtime. Operators must stop the Eclair service, replace the binary with the 0.14.6 version, and restart. ACINQ has confirmed that the software will automatically migrate the local database to the new format, and the new security defaults will take effect immediately upon restart.

Broader Impact and Future Implications

The Eclair update highlights an ongoing tension in the development of the Lightning Network: the trade-off between user experience and security. Features like splicing and dual-funding are essential for making Lightning feel as seamless as a traditional bank account, but they require the network to operate in a state of "optimistic validity" regarding the Bitcoin mempool.

As the Bitcoin fee market becomes more volatile, the pressure to use unconfirmed transactions and low-fee anchors will only increase. However, the Eclair vulnerability serves as a reminder that the Lightning Network is only as secure as its ability to eventually settle on the Bitcoin blockchain. If a Layer 2 state cannot be reconciled with Layer 1 because of a double-spend, the entire value proposition of the payment channel is undermined.

This event is likely to lead to a broader review of splicing implementations across other Lightning implementations. If LND and Core Lightning have similar defaults regarding unconfirmed inputs, they may soon follow ACINQ’s lead in tightening their funding rules. For the broader industry, this reinforces the necessity of "responsible disclosure" programs and the role of independent security researchers in maintaining the integrity of open-source financial protocols.

In the long term, the move toward requiring confirmed inputs may lead to slightly slower channel management for some users, but it provides a much more stable foundation for the routing of large payments. As the Lightning Network seeks to move beyond "coffee-sized" transactions and into the realm of global settlement, these technical refinements are the essential "growing pains" of a maturing financial system. ACINQ’s proactive stance in patching these weaknesses, even before they were exploited in the wild, demonstrates a commitment to the "security-first" ethos that has defined Bitcoin development for over a decade.