New Release: c-lightning 0.9.0

New Release: c-lightning 0.9.0
Multi-part payments, keysend payments, watchtower support, and PSBT everywhere

The c-lightning team is pleased to announce the release of c-lightning v0.9.0. This is a significant release — delayed by a month from our regular two-month release cadence.

c-lightning v0.9.0 encompasses the work of twenty-one c-lightning contributors, eight of whom are first-time contributors! 🎉

Some of the most notable changes with this release:

  • Advanced multi-part payments: The completely rewritten pay plugin will now split payments if the receiver supports it; initially into under 10,000sat parts, then as required when retrying payments. c-lightning has supported receiving multi-part payments since v0.8.0 in December 2019.
  • Support sending keysend payments: The rewritten pay plugin now supports keysend sending (c-lightning has been able to receive keysend payments since 0.8.2 in May 2020).
  • Watchtower support: The plugin infrastructure has been improved so that signed penalty transactions are handed to the commitment_revocation hook, for easy integration with external watchtower services.
  • PSBT internals: The internal transaction representations have been migrated to the Partially Signed Bitcoin Transaction format. This laid the foundation for better integration with other wallets and complex multi-channel negotiations in coming releases.

Multi-Part Payments

Based on Christian Decker’s research on channel capacities and success rates, we’ve leapfrogged from having zero support for built-in, multi-part payments to having an advanced, parallel, multi-part payment implementation. It’s specifically designed to be extended, and that will be a rich source of improvements in the coming c-lightning versions.

By using random segmentation of parts, there are also immediate privacy benefits, since most invoices are a round number of satoshis (which allowed an intermediate node to estimate the distance to the final destination).

A coming post will detail the research and design of our implementation, so the entire network can benefit from more sophisticated use of this feature.

Coin Movements to Keep Accountants Happy

There are many ways that c-lightning spends funds:

  • Opening channels
  • On-chain fees for unilateral closes
  • Sending funds on-chain
  • On-chain fees penalty transactions
  • And many others!

In theory, you could track all of these and query various APIs to reconstruct all your sats, but it’s far better to have a single API that will report all of them in a consistent format.

That’s what Lisa Neigut’s coin_movement API provides: a stream of annotated credits and debits indicating exactly when and how funds are moved. Unfortunately implemented too late for this year’s tax return, it will be an invaluable tool for next year and we expect many plugins to be developed to present this in different formats.

PSBT everywhere

Several of our interfaces already supported the PSBT (BIP 174) format; now Lisa has done a massive internal conversion so they all can.

There are new low-level APIs for manipulating them: fundpsbt asks the wallet to create a PSBT using unreserved inputs to pay for a certain amount of output, utxopsbt uses the given outputs to directly generate the PSBT.

The new reserveinputs and unreserveinputs APIs allow for fine-grained control over what the wallet will use to fund new PSBTs. These APIs now produce RBF-replaceable transactions, too.

In the coming releases, existing interfaces will be migrated over to use these internally. It’s now also simple to implement coin control, replace-by-fee, and simpler-to-implement, multiple, simultaneous fundchannel! And of course, as hardware and other external wallets adopt the PSBT format, integrating them with c-lightning becomes a simple matter of coding.

We’re excited about the new features and groundwork included in c-lightning v0.9.0. Stay tuned for more, coming soon!

If you want to get started using c-lightning or c-lightning development, check out Rusty Russell’s “Getting Started” webinar. We can also be found on IRC (#c-lightning on Freenode) as well as on GitHub reviewing bugs, feature requests, and new code!

Note: This blog was originally posted at https://medium.com/blockstream/new-release-c-lightning-0-9-0-e83b2a374183

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.