After three months and 418 commits submitted by 36 contributors, we are excited to announce the release of Core Lightning v24.02. While mainly a maintenance release, there are numerous smaller changes that node operators will like, as well as some under-the-hood improvements that will make it simpler and more affordable for users to run CLN.
In the following, we will give a short overview of dual funding, which finally left the proposal state and is now part of the specification. Then, we will briefly cover the biggest features and optimizations in this release.
Note: This release contains a fix for a crash bug that may occur on testnet. If you are using CLN on testnet please upgrade as soon as possible.
Dual Funding is Now Widely Available
Lisa Neigut published the first draft of dual funding all the way back in 2017 (a turbulent time), and it has since gone through several iterations. After years of fine-tuning and hardening against abuse, the proposal was finally merged into the Lightning Specification.
This is an incredible step forward for the network as a whole and for CLN and Eclair, which both now support dual funding. Dual funding allows nodes to make better use of their liquidity, obviating the need to open a second channel to contribute funds to a connection. It is also much more robust against misbehaving participants than other balanced channel open protocols: other protocols often allow one party to run away with the funds. In contrast, in dual funding, all parties contributing funds perform a coinjoin protocol, collaboratively creating the funding transaction and not delegating ownership to anybody else, even temporarily. This means that each party is in full and exclusive control of their funds until the channel is entirely created, removing the trust requirements that other protocols have.
At this point, we would like to thank our friends over at ACINQ for working with us on the proposal and providing the second implementation of the proposal, which ultimately allowed us to progress. As a reminder, the two-implementation requirement aims to ensure that the specification proposal contains all the information necessary to implement the proposal and to ensure that the proposal works for more than one implementation. Given the very diverse the user base that CLN and ACINQ’s products have, it was a very nice confirmation that the proposal solves issues for an equally diverse set of use cases.
But the journey is not quite over yet. Part of the dual funding specification also includes the interactive-tx sub-protocol, which also happens to be the enabling feature of splicing. So stay tuned for more exciting features coming up.
New Recovery Plugin
Software bugs and hardware issues are unavoidable in the real world, so it’s important to us that we mitigate the negative consequences where possible. With the real-time backup capabilities we introduced a couple of years ago, we have a system that allows restoring a node without operational impact aside from a brief downtime. However, the real-time backups can be a bit cumbersome to set up, usually requiring a secondary location to write to and regular compression of the backups.
Aditya Sharma followed up on his prior work on building an emergency recovery system similar to the static channel backups (SCB) in other implementations. The static channel backup and our emergency recovery system both consist of a small file that contains metadata about channels that were opened. In case of data loss, we can take that file, expand it into channel stubs, and start connecting to the peers in the hope of asking them to close on our behalf so we can then sweep the funds from the close. This can either be used as a complement to the real-time backups or as a last-ditch effort should you not have the backup configured.
This latest iteration adds the recovery plugin. Where previously you would have to understand and manually step through the recovery process, the new plugin takes care of most of the process. This means that recovery just became a whole lot more reliable. Do not underestimate how important reliability and ease of use are in this case, especially in a situation where your system just crashed on you, and you are trying to recover your funds.
Performance and Stability Improvements
As with every release, this one also includes a large number of optimizations, and while we cannot highlight every single one, there are some broad topics we would like to mention here.
For example, the speed at which we process blocks has been increased by over 50%, thanks to some optimizations in the handling code. This means that if your node is shutdown, it will take less time for it to catch up with the blockchain.
A major rework in the way gossip is handled resulted in the gossip being split into public and private, and the private gossip no longer being stored in gossip_store. This means that the gossip_store file can now be shared among multiple nodes, and you can also provide one when starting a new one, avoiding the re-verification and allowing you to provision nodes much faster.
Upgrade to the Latest CLN Release
Among all the changes, features, and optimizations mentioned above, this release also contains a fix for an issue on testnet. The issue is due to libwally attempting to enforce some relay policies when parsing the block, which does not have to adhere to relay policies. A larger than-allowed transaction in block 2578284 caused libwally to erroneously reject the transaction and then the block. If you are using CLN on testnet please upgrade to v24.02 as soon as possible. Bitcoin mainnet is not impacted.
In addition to the testnet fix, there is also a minor fix in elementsd and regarding Liquid support, where we could fail to parse a peg-in correctly, causing the node to get stuck when attempting to parse the transaction.
To update to the latest version of CLN, head over to the release page, or if you want to dig into the finer points, check out the changelog, and tell us what you like or what we could improve.
And as always, a huge thanks to the many contributors and volunteers who continue to help us improve CLN over time. We are grateful for your contributions and look forward to continuing to partner with you in building Lightning.