Core Lightning v23.08: "Satoshi's Successor" Part I - User Experience

Today, we welcome the latest Core Lightning release, v23.08, codenamed Satoshi’s Successor (courtesy of Matt Morehouse). The August 2023 release has such an overwhelming array of changes we are splitting the release announcement into three separate blog posts:

Part I - User Experience: new features users have requested.

Part II - Developer Experience: new features and enhancements for developers.

Part III - Experimental Features: a look into Lightning’s future by enabling experimental options at runtime.

The next two will be shared tomorrow and the following day, so make sure you subscribe below or bookmark the Lightning blog to stay updated.

Lightning Polished and Stable

We uncovered several cases where channels with Eclair and LND nodes could fail, which we have fixed or made compatible. These are rare, but channel breakage is always annoying.  There are also a slew of minor fixes and tweaks in the 530 changes since the last release; my favorite is the one where, if the only unexpired invoices you had expired after the year 2038, we would loop forever on old 32-bit platforms (which, yes, we still support!).

We added a new parameter to setchannel called ignorefeelimits, to insulate channels against fee disagreements with peers. We had a previous global setting, but this one can be set or unset on more trusted peers dynamically, and will allow them to set on-chain fee rates even if we think they are wrong. In particular, LND will always re-request the same channel fee even if its fee rate estimate has since changed, so setting this temporarily can “unstick” a channel. It turns out that bitcoind forgets the previous minimum real fee when it restarts, too, so nodes can also get confused from that (this has been fixed for the next Bitcoin release).

We also added Taproot address support, thanks to Greg Sanders: you can issue Taproot addresses for people to send you on-chain funds, and we will immediately use them for our own change outputs. Taproot addresses (i.e., P2TR) start with bcp1 instead of bcq1, just so you know!

Updated Plugins and New Commands

Our pay plugin, which drives payments, has some tweaks to make paying faster and more reliable: this is the first concrete feedback from Christian Decker’s work on Greenlight (Blockstream’s developer preview of our hosted, non-custodial Lightning infrastructure), where he analyzed payment failures on the real network and fed the results back into upstream development. No doubt there will be many more such refinements in future versions! The third installment of the blog series will go into more detail on pay and discuss the new experimental renepay plugin!

To help manage your node, there is a new command to change settings without restarting your node: setconfig. This changes the configuration setting dynamically, and also changes it (with a comment) in the correct configuration file so that it is persistent!  This is matched by the power of the update output from listconfigs, which shows you exactly where each configuration setting came from: was it a particular line in a configuration file, the command line, or the default?  The setconfig command is currently only used for setting autoclean limits, but this will expand to more settings in future releases as people request them (we also have an open issue you can add to).

Logging got some work, too: you can now add different filters to different log files. For example, you can have one log file for debug-level logging, and another for normal info-level logs. You can also use this to configure more logging for particular peers or plugins.

Thanks to the Summer of Bitcoin work of Aditya Sharma, you can now save and restore your node’s secret key in the new BIP 93 format (aka. codex32). Unlike BIP 39 seed words, this can be done on all nodes, using the hsmtool getcodexsecret command, and your node restored using the - -recover commandline option. This will also gain more abilities in future releases, such as finding and recovering any existing channels and funds you might have. Our BIP 93 strings look like:

They have some amazing ability to recover from errors which we will be exploring in future, but for now, you would have to make more than eight mistakes before there is any chance we would accept it as valid.

Our reckless plugin manager got more powerful: it can install from local copies of plugins, not just GitHub. That brings everyone a little closer to becoming a developer: grab a plugin, change some things, then get reckless to install and start it for you!

Finally, as part of the fallout of the recent Bitcoin fee spike, Bastien Teinturier of ACINQ noticed that one channel closure can cascade to others, if a payment was in progress and fees increase markedly.  We now handle this case more carefully and will sacrifice a not-worthwhile payment on an outgoing closed channel, to avoid causing incoming channels to fail. This should contain the damage on any unilateral channel close in the future!

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. We also have special developer and node runner pages to help facilitate long-form discussion. It is free to sign up, and nyms are more than welcome!