Core Lightning v23.08: "Satoshi's Successor" Part III - Experimental Features

This is the third (and final) blog post in a series detailing the many changes to CLN in the new v23.08 release, codenamed Satoshi’s Successor (courtesy of Matt Morehouse). The first post covers our improvements to user experience, and the second highlights new features and enhancements for developers.

In the early days of Lightning, developers publicly advised that using real funds was reckless. That is less true today, but we know some of you like to continue that pioneering spirit, so this section is for you (and the rest of us thank you for it!).

And let me just point you at our issues page so your injuries are not in vain.

Firstly, we have eliminated the concept of experimental builds: now every Core Lightning node can enable each experimental option separately, if they want to. This means that we have two new options, which were previously turned on by default in experimental builds: experimental-upgrade-protocol enables simple channel upgrades from old non-static-remotekey channels if both ends enable it, and experimental-quiesce enables temporary stopping of a channel progress (not very useful by itself, but good for other protocols, like splicing!).

Dual Funding Gets an Upgrade

As when we first released it in 2021, experimental-dual-fund will enable dual funding. It allows both peers to contribute funds to channels, enabling complex constructions like coinjoin, UTXO consolidation, and multiple parallel opens for each side; it also allows either side to RBF if your channel does not open fast enough, and an extension called option_will_fund to offer to lease channel liquidity to your peers.  

This version has been tweaked for interoperability with the latest specification draft, and now works with Eclair! With this option in your configuration file, you can negotiate dual funded channels with any peer that supports it!

Splicing Channels, at Last

When you have a Lightning channel, if you want to increase the size of it, you have to open a new channel. To decrease the size, you have to close one (and maybe open a smaller one).  The idea of being able to splice funds in or out of a live channel while it is still going is almost as old as Lightning implementations themselves, so when Lisa Neigut was designing the interactive construction mechanics required for dual funding, splicing in and out of existing channels was kept in the back of everyone’s minds.

Fast forward to today, and my early draft specification for splicing has been rewritten and implemented by Dusty Dettman for Core Lightning. This was Dusty’s first major contribution, and it was incredibly ambitious: dating back to May 2022, with a PR containing over 300 comments, reaching deep into the Core Lightning code. Preparatory work was merged in the last release, and then Dusty continued; the specification details were re-negotiated as the Lightning team from ACINQ started their implementation, causing multiple revisions, and much collaboration with them and Lisa Neigut. It was finally merged on July 31, after final review. Dusty has made numerous refinements since then, including more documentation, and moving the feature bit from the final 63 to an experimental 163 in case the specification changes again.

By restarting your node with experimental-splicing you and any compatible peers can start splicing today with the splice_init, splice_update, and splice_signed commands. Note that some explorers may consider your channel closed for the six blocks between the splice being mined and seeing the new splice announcements: the spec was amended a year ago to give apparently-closing channels 12 blocks before considering them definitively closed. Now we are going to see real splices on mainnet, I expect them to catch up quickly!

Pickhardt Payments, aka Renepay

Rene Pickhard is a well-known Lightning researcher who has released multiple papers on Lightning. One of his collaborators, Eduardo Quintana, was given a grant through Build On L2 to implement Rene’s minimum cost flow proposals in a concrete form, and the result is a (currently experimental) plugin called renepay.

Our current pay plugin does not have a very sophisticated view of the network: it attempts a payment and keeps trying variants until it runs out of time or things to try. Renepay maps out the likely payment sizes for each path and breaks the payment to spread across the most likely ones; it then collects feedback from failures (or partial successes) and continues the process until it has run out of time, or the probability of success is vanishingly small. Importantly, it remembers what it learned from previous payments for up to an hour, so second and further attempts are more likely to succeed.

It is still a new plugin: the simple renepay and renepaystatus commands are under active development and will continue to be enhanced until, hopefully, this becomes the default plugin for Core Lightning in a future release! Meanwhile, feel free to try renepay to pay invoices and report your results!

* Flying car not included

Join the CLN Community

As always, we want to give a special shoutout to all the contributors (31 for the v23.08 release) who continue to help us improve CLN with every update. We are grateful for your support; the new release was only possible with your dedication and feedback.

Let us know what you like or what we could improve by starting a thread on Build On L2 or by commenting via our usual social channels: Twitter, Telegram, or Discord.