Core Lightning v23.05: "Austin Texas Agreement (ATXA)"

Core Lightning v23.05: "Austin Texas Agreement (ATXA)"

We are excited to announce the v23.05: Austin Texas Agreement (ATXA) release of Core Lightning (CLN), named by Gregory Sanders. The May 2023 release packs a lot of exciting new features for CLN users, developers and the network.

PSBTv2 support: CLN's APIs now support both PSBTv0 and PSBTv2. Version 2 is an update that improves transaction sharing by eliminating fixed "global transactions," giving users increased flexibility and security.

RPC methods: Useful new PRC & GRPC methods have been added, including listclosedchannels, commando-listrunes, and commando-blacklist, for improved usability.

msat migration: Removed the “msat” suffix from all millisatoshi fields, as deprecated in v0.12.0.

For a detailed list of all changes in v23.05, review the changelog, which contains many more features and performance improvements, including default blinded paths and more options for fee rates.

PSBT Version 2

Before Partially Signed Bitcoin Transaction (PSBT), transactions were passed between wallets in an ad-hoc manner. There was no standard way of representing intent, how to store non-final signatures, and how to modify fields. BIP 174, or PSBT, changed all this. Now wallets have a common standard to use when sharing incomplete transactions, helping to build consistent cold and hardware wallet interfaces, layer-2 protocols such as Lightning Network, and other smart contracting protocols.

The first iteration has a couple of major drawbacks, primarily the "global unsigned transaction" included in BIP 174. This global transaction cannot be changed, which prevents collaborators from altering the fundamental units of the transaction, namely the inputs and outputs. Another drawback of this approach is knowing how many inputs and outputs a PSBT has; you have to be able to deserialize this global transaction, which a library may not have.

PSBTv2, or BIP 370, mitigated this by removing the global transaction entirely and representing these fundamental pieces in more natural places. Going forward, this will become the standard format. With this update, it will be easier for CLN to completely migrate to this format in future. The RPC interface, by default, still returns PSBTv0, but an RPC endpoint `setpsbtversion` has been exposed to allow v2 support, debugging, and experimentation.

RPC Methods

New RPC methods like listclosedchannels, commando-listrunes, and commando-blacklist methods have been added.

- listclosedchannels is useful for showing old and dead channels. It returns channel data on all historical channels that are otherwise forgotten or filters results to only match channels to the supplied peer ID. Note that prior to v23.05, old peers were forgotten.

- commando-listrunes either lists runes stored at the time of generating them or decodes runes given on the command line. However, runes generated prior to v23.05 were not stored, so they will not appear in this list.

-  commando-blacklist effectively revokes the rune already created (and any runes derived from that rune with additional restrictions) and will return a "Blacklisted rune" error message otherwise. All runes created by commando have a unique sequential ID and can be blacklisted in ranges for efficiency. The command always returns the blacklisted ranges on success. If no parameters are specified, no changes have been made. If you start without a specified end, that single rune is blacklisted, but if the end is also specified, every rune from start to end is blacklisted.

Some sample examples for these methods are as following:

$ lightning-cli listclosedchannels
{
   "closedchannels": [
      {
         "channel_id": "ffd44d19..c30501058",
         "short_channel_id": "2420348x59x0",
         "alias": {
            "local": "1923610x47..69x57056",
            "remote": "807411x97..08x47009"
         },
         "opener": "remote",
         "closer": "remote",
         "private": false,
         "channel_type": {
            "bits": [
               12
            ],
            "names": [
               "static_remotekey/even"
            ]
         },
         "total_local_commitments": 59,
         "total_remote_commitments": 59,
         "total_htlcs_sent": 0,
         "funding_txid": "5810503...d4ff",
         "funding_outnum": 0,
         "leased": false,
         "total_msat": 100000000,
         "final_to_us_msat": 20000,
         "min_to_us_msat": 0,
         "max_to_us_msat": 20000,
         "last_commitment_txid": "db68b02f1f9...6bd69",
         "last_commitment_fee_msat": 159000,
         "close_cause": "remote"
      }
   ]
}`
`$ lightning-cli commando-listrunes
{
   "runes": [
      {
         "rune": "tGS...mVsIw==",
         "unique_id": "2",
         "restrictions": [
            {
               "alternatives": [
                  {
                     "fieldname": "For Application",
                     "value": "",
                     "condition": "#",
                     "english": "comment: For Application "
                  }
               ],
               "english": "comment: For Application "
            }
         ],
         "restrictions_as_english": "comment: For Application "
      }
   ]
}
`
`$ lightning-cli commando-blacklist
{
   "blacklist": [
      {
         "start": 1,
         "end": 2
      }
   ]
}

msat Migration

In Lightning, millisatoshi (msat) is a measurement unit equal to one-thousandth of a satoshi. Core Lightning previously returned all millisatoshi fields suffixed with msat; for example, “msatoshi_sent: 100000msat.” Users were required to strip “msat” and convert the remaining value into a number for any numerical operation. As of v0.12.0, it was deprecated and, in v23.05, it has been entirely removed. Now, all millisatoshi values are received as numbers.

Join the CLN Community

We want to thank all the contributors (17 for v23.05) who continue to help us create a better Core Lightning with every update. We are grateful for the community's support and look forward to working alongside you in future releases as we identify ways to improve CLN.

We hope you will join us on the CLN Build On L2 community platform to continue fostering a strong community. It is free to sign up, and everyone is welcome! And as always, let us know what you like or what we could improve by starting a thread there or commenting via our socials: Twitter, Telegram, or Discord.


Core Lightning (previously c-lightning) is a lightweight, highly customizable and standard compliant implementation of the Lightning Network protocol.

© 2023 Core Lightning
All rights reserved.

Discussion Forum

The official Core Lightning forum is coming soon!

BuildonL2 Community

The official BuildOnL2 community lives at community.corelightning.org. Join us and build the future of bitcoin on lightning.

Mailing List

For general discussions about CLN implementation, use c-lightning@lists.ozlabs.org. For the Lightning Network, use lightning-dev@lists.linuxfoundation.org

Telegram

Community-driven telegram group where most of the node operators hang out. Go to https://t.me/lightningd to join.

Discord

Community-driven discord server where the devs flock together. Go to https://discord.gg/w27fMFESMN to join.

Internet Relay Chat

Don't hesitate to reach out to us on IRC at #lightning-dev @ libera.chat, #c-lightning @ libera.chat.