Core Lightning v24.08: “Steel Backed-Up Channels”
Lightning Network

Core Lightning v24.08: “Steel Backed-Up Channels”

Shahana Farooqui

Three months and 378 commits later, the latest version of Core Lightning, v24.08, is available for update. This release brings notable improvements to offers, pay, and the experimental renepay plugin. 

BOLT12 offers have been updated to support self-payments and blinded paths. The pay plugin has been enhanced with capacity checks, advanced error handling and logging, ensuring smoother and more transparent payment operations. Meanwhile, the renepay plugin now provides greater control over routing with updates such as probability cost function and an exclude option. These plugin advancements, along with improvements such as I/O optimization, documentation accuracy, and refinements to gossipd and reckless, will give users the best Core Lightning experience yet.

Renepay and Askrene

The renepay plugin, first introduced as an experimental feature in v23.08 has undergone significant enhancements in this release. Based on the optimally reliable routing strategy developed by Rene Pickhardt and Stefan Richter, renepay offers a more sophisticated approach to multi-part payments (MPP) compared to the default pay strategy. While the default pay strategy involves computing single paths that minimize fees and splitting the payment amount into two halves to send along two routes whenever a single path fails, the renepay plugin instead solves this by employing a minimum cost flow computation to obtain a set of routes for the payment, where the cost function is a combination of success probability and fees. This approach theoretically offers the most reliable MPP based on the current state of liquidity in the network. The plugin learns from failed attempts, feeding this information back into the minimum cost flow solver for subsequent computations.

In v24.08, the plugin's probability cost function has been refined to include a constant term accounting for the probability that a remote channel will reject forwarding requests independently of liquidity or payment amount. Additionally, a new 'payment modifier' has been introduced to filter out channels with low htlc_max settings, ensuring a more reliable routing experience. The global time scale for network knowledge decay has been extended to a week, reducing the risk of using depleted channels for payments. The new exclude option in the renepay command allows users to exclude specific channels or nodes from route computation, enhancing customization and control.

Complementing these updates is the introduction of askrene, a new plugin that leverages the same routing strategy as renepay but splits the functionality into two distinct plugins—one for querying routing solutions and the other for executing payments. askrene introduces eight new commands, such as askrene-age for aging out outdated constraints and askrene-create-channel for managing specific channel directions. Other commands, like askrene-disable-node and askrene-inform-channel offer greater precision in managing payment routes. The new getroutes command finds optimal paths using layers, providing outputs suited for creating intermediary onion layers, making it a robust toolset for managing payment routes

Pay and Offers Plugins

The pay plugin has been particularly improved in pre-flight payment checks, error handling, and logging. One of the most notable additions is the channel_hint_updated notification, which shares inferred balances and observations across multiple payments. This feature helps retain valuable information about channels likely to fail, improving the success rate of future payments by avoiding these channels. The plugin also checks for sufficient spendable capacity before computing a route, returning clear error messages when capacity is insufficient. This update ensures that users are immediately informed of any issues, enhancing the transparency and effectiveness of payment operations. Additionally, the pay plugin now supports processing BOLT12 invoices even if the node is the head of the blinded path within the invoice, and it can handle payments where the entry to a blinded hop is specified as a short_channel_id rather than a node ID.

Changes to the offers plugin aim to enhance usability, flexibility, and user experience. All BOLT12 specifications are now fully supported. One key addition is the ability to self-fetch and self-pay BOLT12 offers and invoices. The offers plugin now automatically adds a blinded path from a peer when there are no public channels available, enabling unannounced nodes to generate and manage offers securely without exposing their channels publicly. This feature is crucial for maintaining privacy and allowing nodes to participate in the network without revealing their full topology. While processing an invoicerequest, the plugin will automatically set a blinded path for unannounced nodes, ensuring that these nodes can handle requests securely and privately. The sendinvoice functionality has also been improved to use a blinded path in an invoice_request, if specified, and the fetchinvoice process has been refined to attempt all available blinded paths until a usable one is found, effectively handling scenarios where routing requires multi-hop routing.

Other Notable Updates

The reckless plugin manager has also been enhanced with new features. A significant addition is the reckless-rpc plugin, which allows issuing commands to reckless via RPC, providing greater flexibility in its usage. reckless now accepts JSON array input for command targets and offers JSON output with the -j/--json flag for better data handling. Support for installing Rust plugins has been introduced, expanding the range of plugins that can be managed through reckless. Usability improvements, such as making option flags in reckless position-independent, have also been implemented, making command entry more intuitive.

Beyond the developments mentioned above, the release also includes several enhancements to improve performance, protocol efficiency, and documentation accuracy. New I/O optimizations have been implemented to markedly accelerate operations on larger nodes by reducing CPU usage. On the protocol side, Core Lightning now always requests all gossip data from the first connected peer, ensuring comprehensive network information from the start. Furthermore, support for onion messages is now enabled by default, enhancing the privacy and security of communications within the network. To ensure all example code snippets in the documentation are reliable and up-to-date, they are now generated directly from executing the code itself, guaranteeing they accurately reflect current functionality.

Join the Core Lightning Community

We extend our heartfelt thanks to the 21 contributors who made the v24.08 release possible with their 378 commits since the last update. Your commitment to enhancing CLN is invaluable, and we are grateful for your ongoing support.

As always, we encourage you to share your thoughts and feedback on the Build On L2 forum, where you can engage in detailed discussions with fellow developers and node operators. Your insights help us shape future releases and make Core Lightning even better.

You can also connect with us on X, Telegram, or Discord, and stay tuned to the Blockstream YouTube channel for upcoming podcasts featuring key Core Lightning contributors discussing the new release in depth.

Thank you once again to the incredible community and all who continue to contribute to the growth and success of Core Lightning!

If you have specific preferences, please, mark the topic(s) you would like to read: