Summary of Lightning Network news for the 49h week of 2025 (December 1st to December 7th)
Welcome to your weekly summary of noteworthy news and developments in the Lightning Network ecosystem. This issue is a bit delayed because milady and I went on an extended citadel tour. To make up for this, here are a couple pics of those nice castles (château in French) we visited.
And now, on to Lightning! Last week we almost got the grand slam with 3 out of the 4 major Lightning implementations shipping a new release. We also got our quarterly vulnerabilities disclosure from the great Matt Morehouse, with 3 LND vulnerabilities disclosed. Let's dive in!
Core Lightning Release
Version 25.12 of Core Lightning was released bringing:
- significant speed and reliability improvements for large nodes,
- improved wallet backup,
- updates to the splicing implementation to match the latest version of the specification,
- partial (and still experimental) support for Just-in-Time (JIT) channel negotiation as part of the Lightning Service Provider (LSP) specification,
- and of course, many more improvements, bug fixes and new features (full changelog).
Speed & Reliability Improvements
With bigger and bigger Core Lightning nodes appeared some bottlenecks addressed in this release. Optimizations introduced in this release should notably prevent some freezes under high load when trying to inspect a node's operations (using the
bookkeeper plugin). The xpay plugin, responsible for sending payments, also saw improvements with better handling of multi-parts payments (notably to try to conform with expectations from Phoenix nodes) and enhanced liquidity management (see this PR).Wallet Backup
New nodes will now use a 12 words BIP0039 seed phrase as their "master private key" instead of a "bare" 32-bytes secret as was previously the case. Existing nodes still rely on their existing secret.
This also adds support for an optional passphrase and introduces a new derivation format for Taproot wallets, making them standard taproot wallets. Recovering a wallet will also be easier since it can be done directly with the 12-words seed without additional tooling.
Splicing
Core Lightning upgraded its splicing implementation to be on par with new changes in the specification. Be aware that this is a breaking change, and that if you have splicing enabled1 both nodes sharing a channel must upgrade in unisson. See pull requests 8506 and 8646 for more details.
LSP JIT Channels Experimental Support
This release also added experimental support for part of the LSPS2 specification, which details Just-in-Time (JIT) channels negotiation. A JIT channel is a channel that is "opened in response to an incoming payment from the public network to a client, via the LSP". Since a new channel is opened by the LSP (incurring a cost for them) concurrently to a payment being received by the client (i.e. the user, which can always refuse the payment by not revealing the preimage), one party has to trust the other one to some extent. The choice is usually made and advertised by the LSP, which depending on its trust and business models will either:
- open the channel first, and trust the client to actually claim the payment so that the LSP can charge it's channel-opening fee on this first payment ;
- have the client reveal the preimage first and trust the LSP to open the channel and push the amount of the payment, minus the LSP's fee, to the client's side of the channel.
In this release a partial version of the specification was implemented, focusing on the LSP-trusts-client model and without support for Multi-Part Payments.
This is still flagged as experimental, but a great step forwards for LSPs decentralization, and positioning Core Lightning as one of the best implementation choices (maybe along with Eclair) for LSPs, especially now that its book-keeping plugin has been further optimized for larger nodes with millions of events.
LDK Node Release
The Lightning Dev Kit (LDK) is a modular Lightning implementation, meaning that the bare LDK cannot be used as a fully-functional Lightning node by itself. Rather, its modularity allows developers to plug the LDK to whatever data storage, network interface, wallet tools and on-chain data source they see fit. However, the LDK team also maintains the LDK Node, which combines the LDK with the Bitcoin Dev Kit and other useful tools into a library that can be leveraged to create and interact with Lightning nodes. It's not user-facing (i.e. you can't just "install" the LDK Node), but rather code that can be to integrated an existing stack, but with more batteries included that with the LDK itself.
Last week, both the LDK and the LDK Node repositories got a new release, with many things in common since the LDK Node leverages the LDK. Some of them resonate with the Core Lightning release we just covered:
- experimental support for splicing, compatible with Eclair and Core Lightning ;
- support for the client-trusts-LSP model of the JIT channels negotiation specification (LSP-trust-client was already supported).
On top of this, this releases also bring:
- the ability to source chain data directly from a Bitcoin Core node's REST interface (previously only RPC or Electrum-based server were supported),
- keysend payments (i.e. spontaneous, invoice-less payments where the preimage is created by the sender and passed to the recipient (encrypted) inside the onion),
- an initial version of asynchronous payments, with now both server and client side support,
- support for zero-fee commitment channels.
LND Release
LND v0.20 brings, among other things, a lot of gossip and topology related enhancements. Notably, the channel graph is migrated from the existing key-value database to a more performant native SQL database (this is part of a larger ongoing effort to migrate LND from its legacy key-value database system, which has been a major pain point for larger nodes, to native SQL).
LND Vulnerabilities
Matt Morehouse is a software engineer and security researcher currently focusing on improving the security of Lightning implementations, supported by an OpenSats grant. He works closely with Lightning implementation to responsively disclose vulnerabilities, then shares the technical details once the embargo period is over.
Last week Matt Morehouse disclosed 3 LND vulnerabilities affecting versions 0.18.5 and below, 2 of which allowed attackers to steal funds from the node. Node operators are strongly advised to update their node to version 0.19.0 or later.
LND: Excessive Failback Exploit #2
This vulnerability is a variant of another exploit affecting LND v0.17.5 and below, fixed in v0.18.0 and disclosed by Morehouse back in March of this year. The gist of this vulnerability is that, while routing a payment and under some specific conditions, an LND node could both settle the downstream HTLC (i.e. pay the next node in the route) and fail the upstream HTLC (i.e. refund the previous node in the route) at the same time, leading to loss of funds. This would happen when:
- the downstream node reveals the preimage and claims the HTLC,
- the victim node turns to the upstream node to in turn claim the HTLC by revealing the preimage, but the upstream node doesn't respond,
- in the meantime, the victim and downstream nodes start transitioning from the "in-flight HTLC" state of the channel, to the new state where the value of the HTLC has been sent from the victim's side to the downstream's node side, and the HTLC is not in the channel anymore. The victim node sends its signature for the new commitment transaction to the downstream node, but the downstream node (which now has both signatures for the new commitment transaction) refuses to revoke the previous one and force-closes the channel by publishing the new commitment transaction.
At this point, LND notices that the published commitment transaction has one less in-flight HTLC than the latest valid commitment transaction it holds for this channel. Normally, this wouldn't be a problem because it still remembers that it has already sent the preimage upstream. However, if the node is restarted in the meantime (for example by leveraging a DoS attack vector), it would forget about the preimage, understand the difference between the published commitment and the one in its database as meaning the payment failed, and hence fail the HTLC upstream. The downstream node could therefore claim the HTLC with the preimage, while the upstream node gets a refund for the same HTLC, leaving the victim with a loss.
That's for the previous vulnerability, affecting v0.17.5 and below. The new one disclosed last week is very similar, except that the commitment transaction being published is LND's instead of the downstream node's. The same attack could hence be triggered by the attacker simply by having the victim force-close the channel themselves (which is easy to do, for example by returning an error message).
The mitigation is similar to the one for the previous failback exploit: preventing the failback of an HTLC for which the preimage is already known.
LND Infinite Inbox DoS
This one is a denial-of-service attack that doesn't directly allows an attacker to steal funds, but can be used that way in conjunction with attacks such as the excessive failback exploit we just covered.
This DoS attack causes the LND node to run out of memory and crash. To do so, an attacker can open many p2p connections to the victim and spam it with messages. Since LND queued up to 1,000 messages per peer and allowed too many peers, with a maximal message size of 64 kB a node with 8 GB or RAM could be remotely crashed in minutes.
The mitigation consists in reducing the queue size (from 1,000 to 50 messages) and allowing only 100 connections from peers without channels.
LND Replacement Stalling Attack
Leveraging this vulnerability, an attacker could steal almost the total capacity of the channel shared with the victim at a fixed cost.
When a channel is force-closed with in-flight HTLCs being routed from A to B, a race begins for node A to have this close transaction confirm before the upstream HTLCs (sent by a previous node to A) expire, or else the value of these HTLCs could be completely lost (they could be refunded to the upstream node(s) while the downstream node(s) (e.g. B) claim the in-flight HTLCs on-chain with the preimage).
To ensure a quick-enough confirmation of the closing transaction, LND uses a sweeper which batches the spending of multiple claimable unspent outputs that have the same deadline in one transaction, and aggressively increase the fee-rate of this transaction (though RBF) as the deadline approaches. However, if one of these UTXOs which are being used as inputs of the sweep transaction is double-spent while the transaction sits in the mempool, LND crafts a new sweep transaction (leaving out the double-spent output) but mistakenly resets the fee-bumping strategy. An attacker could therefore tamper with LND's sweeper's fee-bumping strategy by sending many HTLCs to themselves through the victim's channel and claiming them on-chain one-by-one using the preimage. Each time the attacker claims an HTLC, LND's fee-bumping strategy resets to the lower initial fees and, with enough in-flight HTLCs and a sufficiently low CLTV delta, the attacker could steal the value of any remaining HTLC(s) at their expiration.
Matt Morehouse gives the example of an attacker opening a direct channel to their victim and sending 40 HTLCs to themselves through this channel, using the minimum default allowed value of 80 blocks for the CTLV delta. The attacker wants to steal the last HTLC, so the 39 others can be as low as the dust limit, and the last one could be as close to the full channel's capacity as possible. Then, the attacker holds the HTLCs until they expire and the victim force-closes the channel. At this moment, the 80-blocks window opens. Since all 40 HTLCs share the same deadline, LND's sweeper batches them as inputs of one sweeping transaction and broadcasts it.
Seeing the transaction in their mempool, the attacker then claims one of the low-value HTLCs on-chain using the preimage. By paying enough fees (estimated by Morehouse at around 4,500 sats/HTLC under current network conditions), the attacker's transaction spending the HTLC replaces the victim's sweeping transaction, which becomes invalid since it tries to spend an output that was already spent. LND would wait one block after the replacing transaction confirmed before crafting and broadcasting a new sweeping transaction that resembles the previous one, just with one less input (the claimed HTLC). Crucially, at this point LND also resets the fee-bumping strategy to the initial lower fees. By repeating this every time LND publishes a new transaction (i.e. every 2 blocks at most), the attacker ensures that LND's sweeper never actually increases the fees. After 80 blocks, the last HTLC standing expires upstream and the sweeping transaction is still unconfirmed. The attacker can then claim both upstream and downstream HTLCs (respectively via the timeout and the preimage paths), stealing the HTLC amount from the victim.
In an "Attack Cost" section, Morehouse estimates that this attack could cost as low as ~100,000 sats. Crucially, this cost doesn't scale with the "stealable" amount (nearly the whole channel capacity), making this attack very cost-efficient.
This vulnerability was fixed in v0.19.0 of LND by eliminating the reaggregation delay (the fact that LND would wait for the next block after the replacing transaction confirmed before broadcasting a new sweeping transaction) and not resetting the fee-bumping strategy between broadcasts.
That's it for this week. Thank you for reading so far! If you have any comment or feedback, please do share them, I'll read them all. Until next week!
Footnotes
-
Splicing is still marked as experimental in Core Lightning, and hence turned off by default. ↩