We told you 24.08, 25.05 and 25.09 had enhancements, but you haven’t seen anything like this! We know we’re biased, but this release is full of enhancements, optimizations and, you guessed it; biases!
- BIP-39 12-word recovery phrase
-
xpay improvements from deployment feedback- A vast array of performance improvements for large nodes
-
networkevents subsystem to access information about peers: ping times and connection times- Exper!mental features: incompatible splicing and recurring offer changes
Mnemonic-ally Speaking
Updating our BIP39 Mnemonic Support and Improved Wallet Recovery
Core lightning nodes have historically generated a 32-byte hex seed: cryptographically cool, not so easy to store. Now, newly created core lightning nodes will open with a BIP39-compatible mnemonic secret. This improvement feature allows you the ease of backing up your node with a standard 12-word recovery phrase, making your life easier to securely store and manage your credentials.
We salute existing node runners: your nodes will continue to work exactly as before with their current hsm_secret format, giving you full backward compatibility.
As long as you have a backed up recovery phrase (even for a core lightning node), you can now recover your on-chain funds using any BIP39/BIP86-compatible Bitcoin wallet; because we’ve implemented standard BIP86 wallet derivation for taproot addresses for nodes initialised with a mnemonic.
`xpay` levels up
We rely on feedback from our open source community, and after 25.09 you really delivered, here are a few highlights of the xpay improvements we've made because of your feedback and contributions:
- Fixed a clash with simultaneous payments via
routehintsand blinded paths. - To mimic the behavior of
pay,xpaywill now wait if it suspects a payment failure is due to a height disagreement with the final node. xpaywould sometimes leave a payment part statuspendingif it failed because a peer vanished. This showed up as pending payments inlistpaysorlistsendpays. We fixed that, and fix any ones left over when you upgrade.- Paying Phoenix clients is more reliable! Based on feedback about limits of HTLCs (6 is Phoenix's limit),
xpaywill restrictmaxpartsto 6 for non-public nodes, no longer trying to send more than 6 HTLCs through unknown channels unless it has no choice.
Enhancements? 'Show me the money data!'
Whether you’re on the Postgres or Sqlite3 team, there’s enhancements for every database and every node size! Rather than telling you, here are some of the numbers:
xpay uses filtering on rpc_command so we only get called on pay.
- Time (from start to end of l2 node): was 227, now just 135 seconds.
- Worst latency: was 62.4, now just 12.1 seconds.
We have told the database not to create an explicit transaction for read-only operations, since we are the only writer, we don't need one. This gives a nice 30% speedup on Postgres!
We always start a transaction before processing, but there are cases where we don't need to. We have switched to doing it on-demand: we’re not going to start database transactions unless we really need to. This will make a big difference to Postgres users by reducing the latency to more than 12%.
Sql users, we’re limiting how many chainmoves and channelmoves entries we ask for at once to avoids latency spikes when we ask lightningd to give us 2M entries.
- Worst latency: was 4.5, NOW 0.028 seconds!
lightningd steps up too!
We’ve improved everyone’s favorite daemon: lightningd in a few ways:
We will no longer loop through all commands every time one finishes. When we have many commands, this is where we were spending all our time:
- Time (from start to end of l2 node): was 34 now JUST 13 seconds
- Worst latency: was 24 now JUST 4.0 seconds!
Some changes to help lightningd handle large numbers of command outputs gracefully. Profiling showed we were spending all our time in tal_arr_remove when dealing with a giant number of output streams; we now use linked list instead.
- Time (from start to end of l2 node): was 518, now JUST 239 seconds
- Worst latency: was 353, now 56.9 seconds
And no longer shall lightningd copy hooks array into hook request, this didn’t scale. Rather than shrink, we will simply NULL out the array in the plugin_hook.
- Time (from start to end of l2 node): was 85, now JUST 34 seconds
- Worst latency: was 75, now JUST 24 seconds
Keeping Tabs on a Lightning-Fast Network
Lightning nodes are constantly evolving. To help manage this, Core Lightning uses the networkevents subsystem to centralize all network-level notifications. As the network evolves, as do our enhancements! We’ve expanded the subsystem to access information about peers: ping times and connection times.
- `sql` now supports the `networkevents` table
- `delnetworkevent` to delete from listnetworkevents
- `wait` now has `networkevents` subsystem
We wouldn’t be cln without pushing some boundaries and dipping our fedora hats with a gentle nod to the spec…
- In true linear fashion, the next step for LSPS0 and LSPS1 compliance, we’ve added
experimental-lsps-clientandexperimental-lsps2-servicesupport for LSPS2 - We’re increasing our conformance to Bolt spec for splice commitments. Peers must now upgrade in unison!
- Woops! We had accidentally crashed when splicing with a channel that hadn’t been announced yet, so we’ve fixed that.
- To keep up with the BOLT 12 recurring offers: Core Lightning will no longer accept old recurring offers and you will need to use an expiry if you need to restrict when they can start using the offer… but when using an expiry, use years, not months!
We held this release back by a few days; not in defiance of Blockstream’s management, but because in the eleventh hour, Rusty cracked the case of the elusive missing_utxo bug.
You may have spotted the three point releases since 25.09, and for good reason. Alongside a bug fix and feature-packed update, we’ve devoted substantial effort to fixing crashes, resolving regressions, and strengthening our testing (including reducing time of CI!) to ensure smoother, more reliable results.
Acknowledging Our Contributors:
A special thanks to Blockstream’s nonpareil Core Lightning team for their continued dedication to this project: Rusty Russell, Shahana Farooqui, Sangbida Chaudhuri, Alex Myers, Christian Decker, Eduardo Miranda, Peter Neuroth and Lisa Neigut.
Since our last release, 25.09, there have been 520 commits from 24 authors in 92 days, including contributions from three developers: @wqxoxo, @noblepayne, @claudio.raimondi and @botantony.
Big props also go to @Sangbida who named this release carrying on our strong IYKYK vibe.
Thank you to the loyal open source community members contributing to the project and tackling (and patiently waiting to be allocated their bounty rewards). You can explore the other open CLN bounties at their new home on the core-lightning #bounties server on Discord.