Today, we welcome the latest Core Lightning release, v23.11, codenamed Bitcoin Orangepaper (courtesy of Shahana Farooqui). After the huge v23.08 release, this update is a bit smaller in scope and mainly offers improvements and follow-ups. Nonetheless, it includes some noteworthy features that we are excited to share with you.
Dual funding reached compatibility level: After a long journey, the dual funding process finally reached cross implementation compatibility.
RPC command updates: This release has some exciting additions and updates for the Core Lightning API, including a much more powerful check command and a brand new restore command.
Core Lightning for developers: Core Lightning’s various interfaces keep growing and runes got an exciting new field. We also got some new options!
Dual Funding within Reach!
The dual funding proposal has been around for several years now. Since Core Lightning was the first Lightning node to officially support dual funding, it's no surprise that we are fans so let’s talk about it once more!
During a traditional channel funding process, the funding transaction is funded solely by the party who initiates a new channel. This means that, despite being created cooperatively, only this party can add inputs and outputs to the funding transaction.
Using the interactive dual funding protocol, both parties can participate in the funding process by contributing inputs and outputs to the funding transaction (interactive-tx sub-protocol). This is accomplished by sharing updates regarding their desired inputs and outputs during a negotiation phase. Once both parties agree on their additions to the funding transaction, they exchange a necessary set of signatures and can proceed to finalize the funding transaction and the initial commitment transaction.
This process allows for the creation of channels with non-zero balances on both ends. One advantage of this is the ability to establish channels for instant payment sending and receiving without any prior balance shift.
Let’s get to the news now:
A fundamental aspect of the BOLT specification process is the requirement for two separate and compatible implementations of any proposal before it can be included in a BOLT.
Lisa Neigut's recent contributions to the implementation of dual funding in Core Lightning allow the funding process to continue in the event of a temporary connection loss. This was the final step for Core Lightning and Eclair to achieve cross-compatibility.
RPC-Command Updates
This Core Lightning release brings some notable updates and additions to the API.
Building on the foundations laid by the previous release's --recover option, this version elevates it to an RPC-command recover that is accessible through plugins and various interfaces. Behind the scenes, the command causes the node to restart with the --recover option enabled. This feature is especially advantageous for front-end applications.
Together with the introduction of recover, check received a significant upgrade, becoming even more powerful. In addition to validating command format and parameters, check conducts a thorough analysis without altering the system's status.
The conjunction of both commands allows one to check if a recovery can be performed without actually doing so, which can be helpful to build robust user interfaces.
Another example for the improved capabilities of the check command is the delinvoice command. delinvoice utilizes the parameters label and status to remove an invoice from the database. Previously, the check command validated the form of the command by ensuring the presence of both required parameters. With this update, check conducts a deeper analysis checking the presence of an invoice with the given label and confirming that the status aligns.
Example:
$ lightning-cli check delinvoice "l1" "paid"
{
"code": 906,
"message": "Invoice status is unpaid not paid",
"data": {
"current_status": "unpaid",
"expected_status": "paid"
}
}The decode command has also been updated. decode can now handle an emergency recover string, which allows a user to verify the integrity and validity of the emergency.recover file. The emergency recover string can be obtained with the new getemergencyrecover command of the hsmtool.
These updates provide a robust framework that will make it easier for users to operate their Core Lightning node in a secure way.
Speaking of securely operating a Core Lightning Node, runes got a new restriction that allows for more flexibility and fine-grained access management. The per constraint allows for general rate limiting and accommodates a range of time units such as sec, msec, etc. To enable this, Core Lightning now keeps track of a last_used timestamp per rune that is also added to the showrunes command.
This release also updates all time fields to nanoseconds. This affects the listforwards fields received_time, resolved_time as well as listpays and listsendpays created_at field.
In addition to recover, which makes Core Lightning more accessible to front-end applications, the wait and pagination APIs have been extended. wait now supports two more subsystems listforwards and listsendpay. These updates allow waiting for any status change on forwarded HTLCs and payments, and add pagination to listforwards and listsendpays. These additions are particularly useful for front-end developers to improve the user experience. To make these available to a wider audience, the wait system has been enabled on the Rust and gRPC interfaces.
Another neat command that has been added to Core Lightning's utility arsenal is datastoreusage. This command provides a clear view of the database space occupied by datastore entries without the need to manually quantify the data.
This suite of command updates not only enhances Core Lightning's functionality, but also improves the user and developer experience, underscoring the platform's continued evolution.
Other Notable Updates
With this release, Core Lightning has buried the old way of enabling developer functionality on a node. Previously, it was necessary to compile Core Lightning from scratch. To enable developer functionality, one now simply needs to start lightningd with the --developer runtime variable. This is a huge simplification for developers.
Core Lightning now enables large channels by default. During the early development of the Lightning Network, the developers decided to temporarily limit the maximum channel size to less than 0.16777216 BTC. This decision was made to limit the amount a user could lose due to software bugs. Nowadays channels can exceed this limit but a node must signal its support and willingness to do so. This release sets the indicators by default enabling “wumbology for all”. Users can still disable wumbo channels by setting the --large-channels=false option.
Finally, this release also adds the ability to create invoices that include a fallback P2TR address. This way an invoice can also be paid on-chain, for example, when there is not enough inbound liquidity at the time of payment. Core Lightning now tracks payments to fallback addresses and resolves any waiting commands. The fallback addresses can be enabled by setting the configuration option invoices-onchain-fallback.
Join the CLN Community
We want to give a shout out to the contributors (a total of 29 for the v23.11 release) who continue to help us improve CLN with every update. We are grateful for your support; your dedication and feedback made the new release possible.
As always, let us know what you like or what we could improve by starting a thread on Build On L2, where we have special developer and node runner pages to help facilitate long-form discussions. It is free to sign up, and nyms are more than welcome!
You can also reach us on our usual social channels: Twitter, Telegram, or Discord.
One more surprise: keep your eyes on the Blockstream YouTube channel. We have a string of special podcast episodes featuring Rusty Russell, Christian Decker, and other CLN contributors, where we detail the new release.
Thanks again to the community and all those who continue to make Core Lightning great!