Critical Bitcoin Lightning bugs exposed nodes to fund theft and restart failure

Lightning Development Kit, a toolkit for building Bitcoin Lightning applications, released v0.2.6 on Sept. 9 with fixes for bugs that could divert small amounts of a node’s funds or prevent saved channel state from loading.

LDK packages a Lightning implementation as a software development kit for uses including mobile wallets and payment-service infrastructure. The update gives developers maintaining affected applications fixes for both a financial risk and a condition that can disrupt normal node restarts.

A splice lets a node add funds to or remove funds from an existing payment channel. LDK’s API documentation describes this as spending the channel’s funding output and replacing it with a new one. In practical terms, it changes the money committed to the channel through a replacement funding transaction.

That transaction has costs shared between the participants. The initiating node pays fees for specified common parts, along with its own contributed inputs and outputs. The fee calculation therefore affects how much of the node’s money pays for the operation.

The splice flaw could let a malicious peer cause excess fee allocation, with the excess going to that peer’s output. The release describes a small amount of funds at risk when a node initiates a splice, without specifying a numerical ceiling.

The separate security flaw involved two payment contracts sharing the same payment hash. After one had been successfully forwarded, receiving and immediately rejecting a bogus one could leave ChannelManager state unable to load.

ChannelManager is LDK’s component for managing channels and payments. Restarting an existing node involves reading its saved state back into memory, a process called deserialization. If that saved state is rejected during loading, the application cannot complete its normal restart. Rejecting the bogus payment does not, by itself, avoid this particular failure.

For wallet builders, the two fixes address different parts of keeping a payment service running: allocating funds correctly when a channel changes and retaining state that can be loaded after a shutdown.

LDK’s architecture documentation explains that its core implementation is compiled into applications. Developers choose the surrounding storage, wallet, networking and blockchain-monitoring components. Incorporating the patched toolkit into those applications is therefore the relevant maintenance step for affected integrations.

The release notice reports no observed losses or exploited applications. Its description establishes the vulnerabilities and fixes, rather than a measured toll on users. With v0.2.6 available, the immediate task for affected application teams is to bring those fixes into the software they operate.