New Release: c-lightning 0.9.0
Multi-part payments, keysend payments, watchtower support, and PSBT everywhere
By Rusty Russell
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 supportskeysend
sending (c-lightning has been able to receivekeysend
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!