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!