Core Lightning v22.11: "Alameda Yield Generator"

We're pleased to announce the v22.11 Alameda Yield Generator release of Core Lightning, named by Alex Myers. Yes, you read that right, we're changing the versioning scheme (more on that below), but first let's talk about the big changes since the previous release:

• reckless is a new plugin manager that you can use to install and uninstall plugins with a single command.
• autoclean has become much more powerful and efficient, especially for larger nodes.
• A new filter API can be used to extract only fields you are interested in from most JSON-RPC commands.

Of course, we can't list all the changes here, and these are just the highlights. The detailed changelog contains many more features, performance improvements, bug fixes, and some deprecations, so make sure to give that a look too.

Reckless

From the very start of the project, we've invested in making CLN as extensible and personalizable as possible through plugins. While the capabilities of plugins grew over time - by adding hooks, notifications, and RPC methods - managing those plugins have remained the same. Installing a plugin, for example, involved a number of steps:

• Copy the plugin onto the node's host (usually by cloning a git repository)
• Install dependencies, if any
• Tell lightningd to start the plugin, by adding a line in the configuration file (plugin=/path/to/plugin), and then starting  the plugin via lightning-cli plugin start /path/to/plugin.

With reckless, we have built a tool that does all of these steps for you, avoiding any issues that might emerge from missing dependencies, wrong paths or missing permissions. On top of this, it also allows operators to search for plugins from our community repository. reckless will be installed as a standalone tool alongside CLN itself.

$ reckless help
usage: reckless [-h] [-d RECKLESS_DIR] [-l LIGHTNING] [-c CONF] [-r] [-v] {install,uninstall,search,enable,disable,source,help} ...

positional arguments:
  {install,uninstall,search,enable,disable,source,help}
                        command
    install             search for and install a plugin, then test and activate
    uninstall           deactivate a plugin and remove it from the directory
    search              search for a plugin from the available source repositories
    enable              dynamically enable a plugin and update config
    disable             disable a plugin
    source              manage plugin search sources
    help                for contextual help, use "reckless <cmd> -h"

options:
  -h, --help            show this help message and exit
  -d RECKLESS_DIR, --reckless-dir RECKLESS_DIR
                        specify a data directory for reckless to use
  -l LIGHTNING, --lightning LIGHTNING
                        lightning data directory (default:~/.lightning)
  -c CONF, --conf CONF  config file used by lightningd
  -r, --regtest
  -v, --verbose

Installing a plugin now is as simple as calling reckless install summary in your terminal. reckless will download the plugin, add it to your core-lightning configuration and start with the plugin enabled. For more information on how to use reckless check the reckless documentation.

As reckless needs to know how to handle and install the dependencies of a plugin, this first version only supports python plugins. We are working on a broader support, e.g., for javascript, golang and other popular programming languages. Stay tuned and tell us what languages you need support for, and what features you're missing.

Keeping Nodes Performant

Core Lightning has always focused on being a highly performant implementation of the Lightning Network with a small resource footprint. However, as the network grows and more and larger operators rely on CLN nodes, we decided to go even further on performance optimization with this release by revising the built-in autoclean plugin. The autoclean plugin learned some new tricks on performance optimization and has become significantly faster. It can now automatically delete old forwards, payments and invoices based on parameters such as age or status. By batching those operations, the execution became way more efficient and time-saving.

For some operators this lead to a shave of several hundreds of megabytes from their databases, executed in a fraction of the time it would have taken before.

More specifically, for each subsystem autoclean will track how many entries have been successfully pruned. These subsystems include:

• Payments: both successful and failed payments can be cleaned, while still maintaining proof of payment.
• Invoices: similar to payments, both paid and expired invoices can be cleaned up.
• Forwards: forwards are likely the biggest issue operators are facing, as they can accumulate rather quickly. autoclean will clean these up as soon as possible.

Call autoclean-once manually or set autoclean-expiredinvoices-age in your configuration to run it in the background, and use autoclean-status to see the current status.

In addition, some performance regressions have been squashed, among a few slowing down node startup and block processing.

What's in a (Version) Name?

Since the beginning of the project, we've aimed to publish releases on a regular cadence every three months. There are a number of reasons behind this, but the most important ones are:

• The Lightning specification is a fast-moving target, and long release cycles slow the spec development down.
• Getting features to users quickly: the longer the release cycle the longer users must wait for features and bug fixes.
• Preventing pre-release crunch: since the next release isn't too far away, we can defer features to the next release, if they're incomplete or haven't been fully tested. This prevents us from releasing a rushed, untested feature due to time constraints.

This time-based release cycle leads to a poor semantic versioning scheme. So we decided to switch to a date-based scheme to better reflect this reality. Nonetheless, we maintain the strong backward guarantees we have always had. Any change in the public APIs is marked as deprecated and will remain functional for six months or two releases after the deprecation has started.

If you are a developer building on top of CLN, always test with --allow-deprecated-apis=false, so you can see when a deprecation may affect you.

Join the CLN Community

With the v22.11 release, we have added a number of usability features, both for private and large routing node operators. But none of this would have been possible without the amazing feedback from CLN operators themselves, and we would like to thank you all for your help!

We also want to give a special thank you to all the contributors who continue to help us improve CLN with every release. We're grateful for your contributions, support, and look forward to continuing to build alongside you all.

You can update to the latest version of CLN by heading over to the release page, or if you'd like to see more details, check out the changelog. Also, feel free to let us know what you like or what we could improve on via Twitter, Telegram or Discord.

Subscribe to have the latest announcements and most bleeding-edge research from Blockstream delivered to your inbox. For further updates, follow us @Blockstream and join the conversation in our Finance, Green, Jade, Liquid, and Satellite community Telegram channels.