The c-lightning team is pleased to announce the v0.9.1 release of c-lightning. This release builds on the infrastructure work in our last release, by 15 contributors from all over the world (including three first-time contributors) and comprising 391 commits.

Some of the biggest changes coming with this release:

• Across-the-board speedups
• Multi-part payment fixes and refinements
• New multifundchannel plugin

Details of these updates are provided below.

1.1 Speedups Everywhere

We had a bug report that listpays was slow and started digging. Creating a node with 50,000 payments listpays took over 50 seconds! By revisiting some unpolished corners of our JSON code, we have reduced that to 1.5 seconds.

This inspired Christian to optimize our JSON-reading code which reads blocks from bitcoind; this is particularly important if a node has been offline for a long time. After a week of downtime, digesting those 2000 blocks would take 16 minutes. The problem here is that the block is a single, two-megabyte JSON string, and as bitcoind sends a little more, lightningd would repeatedly try to parse the JSON only to realize the string was unfinished. After some simple optimizations, this is now down to 6 minutes; that’s up from 2.1 to 5.4 blocks per second.

1.2 Multi-Part Payments Enhanced

Back in version 0.8.0 last year, c-lightning started accepting multi-part payments, but only started sending them in version 0.9.0 (the previous release). Our implementation is fairly ambitious: it will preemptively split large payments where possible. This turned out to be too aggressive with large payments, and there were also issues with combining route hints in invoices and multi-part payments and other bugs which made payments less reliable than they could be. These are all fixed, and like all things which simply work the first time, you shouldn’t notice.

We also changed our invoice logic: we would previously add a route hint to invoices (the so-called routeboost) if we knew an incoming channel had capacity for the payment, and otherwise give a warning. We now add multiple hints if a single channel isn’t enough: this is useful if the payer supports multi-part payments.

1.3 multifundchannel Plugin

Since 0.7.1 we have supported the ability to split channel opening into parts using fundchannel_start and fundchannel_complete, so they could be done using an external wallet or combined with other transactions. But using these was awkward and error-prone, and so our pseudonymous core developer ZmnSCPxj built two new commands on top of the PSBT support that was added in the previous release.

To test this, we attempted to multifundchannel from our testnet node to all 1837 nodes at once. Some we already had channels to, and many are unresponsive (people tend not to cleanly shut down or maintain their testnet nodes!) and two had to be timed out manually, but after many minutes it successfully opened 106 channels in a single transaction.

In fact, the fundchannel command has been rewritten on top of multifundchannel, with no user-visible changes, so you’re using multifundchannel for every transaction now, without changing anything!

1.4 Roadmap and Development Meetings

We have started having regular online Jitsi meetings for developers, with the URL announced on #c-lightning on the Freenode network: these run at the same Monday 8PM UTC time as the Lightning Specification meetings, but on alternate weeks. Come along and ask questions or just hang out with us while we each discuss what we’re doing!

We don’t have a roadmap, as such, but we have started a highlight list to indicate what people want to work on, placed on the c-lightning development wiki.

We’re excited about all the development activity on Lightning—join us!

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