{"id":13192,"date":"2026-09-13T23:01:26","date_gmt":"2026-09-13T23:01:26","guid":{"rendered":"https:\/\/cryptonews.uk.com\/?p=13192"},"modified":"2026-09-13T23:01:26","modified_gmt":"2026-09-13T23:01:26","slug":"ldk-0-2-6-fixes-lightning-fund-diversion-and-restart-bugs","status":"publish","type":"post","link":"https:\/\/cryptonews.uk.com\/?p=13192","title":{"rendered":"LDK 0.2.6 fixes Lightning fund diversion and restart bugs"},"content":{"rendered":"

<\/p>\n

\n

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\u2019s funds or prevent saved channel state from loading.<\/p>\n

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.<\/p>\n

\n

Related Reading<\/span><\/p>\n

Onslaught of AI-found bugs forces Bitcoin’s Core Lightning into a secret 14-day emergency lockdown<\/h3>\n<\/p>\n

<\/span> <\/div>\n

A splice lets a node add funds to or remove funds from an existing payment channel. LDK\u2019s API documentation describes this as spending the channel\u2019s 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.<\/p>\n

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\u2019s money pays for the operation.<\/p>\n

The splice flaw could let a malicious peer cause excess fee allocation, with the excess going to that peer\u2019s output. The release describes a small amount of funds at risk when a node initiates a splice, without specifying a numerical ceiling.<\/p>\n

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.<\/p>\n

ChannelManager is LDK\u2019s 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.<\/p>\n