New Release: c-lightning 0.7.2

Extended plugin features and dynamic add & remove

Rusty Russell
Aug 21, 2019 · 4 min read

Written by Rusty Russell

The c-lightning team is proud to announce the v0.7.2 release of c-lightning. This is the first of our new “every two months” timed releases, and it has improvements across the board. This is a recommended upgrade!

  • Plugin improvements: External contributor Antoine Poinsot contributed dynamic plugins: this means you can now add and remove plugins to a running lightning daemon without restarting.
  • New plugin notifications: invoice_payment tells you when an invoice has been paid, forward_event tells you when an HTLC is forwarded and channel_opened tells you when a new channel has been opened.
  • Better handling of peer errors: together with Connor Fromknecht of Lightning Labs, we diagnosed and fixed a problem where we would receive a mysterious “sync error”. We now ignore this, as it was responsible for the majority of unilateral channel closes we were seeing.
  • Better startup documentation: the file has been overhauled, lightningd now has its own manual page, and there’s a helper script to connect you to a few long-lived nodes when your node first starts up.

A New World of User-Friendly Plugins

Restarting your node to test plugins is somewhat painful for developers: Christian wrote an which helped, but users also want to play with the growing library of plugins.

Enter the new plugin command:

  • plugin stop and plugin start stops and starts plugins, unless they’ve specifically marked themselves dynamic: False.
  • plugin rescan rescans directories for any new plugins and starts them up.
  • plugin startdir adds a new directory to the list plugin directories to search, then starts any plugins it finds there.
  • If you create a plugins directory inside your .lightning directory, lightning automatically includes that and any immediate subdirectories: a useful place to put all your personal plugins!

Another minor, but important feature for usability: plugin commands can return "format-hint": "simple" in their responses to make lightning-cli default output be human readable rather than JSON. This allows your plugin to do its own formatting, allowing implementation of a plugin to be more natural (I can’t believe this doesn’t exist yet!).

For more details on the specifics of plugin hooks and notifications, please see the . And don’t forget to submit your plugin to the c-lightning on Github.

A Plague of Channel Closings, Cured

We had some disturbing reports of mass channel closings, caused by peers sending an error packet with the simple word “sync error”. We suspected some subtle integration issue, but were unable to reproduce it, and we even went so far as to test all the corner cases of reconnection in the specification. Worse, it seemed to cluster: lost eight channels at once on one restart, and there were similar bug reports of mass closings.

We patched lightningd to back off and try again when this error occurred (instead of simply closing the channel), and funded channels to all the nodes mentioned in bug reports to maximize our chance of seeing it again. Indeed, we did, and ignoring it and retrying seemed to eventually resolve it. But we still needed to know why it happened, and whether it had some sinister cause.

With the help of Connor Fromknecht we managed to coax our node into reproducing it against his node. Because that node runs permanently under the debugger to catch any errors, it can be so slow that it triggers lnd’s internal timeout which causes this mysterious error!

With that understanding, we knew our fix was correct. And to prevent such overload, we also now limit the rate we reconnect to everyone at restart; after the first five channels, we wait about a second between each one. This means even Rusty’s should be able to handle a few more channels.

More Protocol Experiments

There’s long been an option when you build c-lightning, called --enable-experimental-features; it just hasn’t done anything until now. With 0.7.2 it adds a , so you can ask for a dense summary of channel updates and selectively query them; Eclair’s mobile wallet has seen impressive speed gains from its use, but the specification is not yet finalized.

This option allows us to test interoperability with them (such 2-implementation testing being a requirement for final spec inclusion) as well as selectively deploy it if all goes well in the final phases.

The increased attention on the specification lead us to work on: for the protocol, which revealed a longstanding bug fixed in this release. For future compatibility, nodes should ignore , but simple testing revealed that we weren’t doing that. It’s good to solve that now, before we need it!

If you want to get started using c-lightning or c-lightning development, we can be found on IRC (#c-lightning on ) or the as well as on GitHub reviewing bugs, feature requests, and new code!

Blockstream Engineering Blog

The latest developments in cutting-edge Bitcoin technology from Blockstream.

Rusty Russell

Written by

Rusty is a Linux kernel dev who wandered into Blockstream, and is currently trying to produce a prototype and spec for bitcoin lightning. Hodls bitcoin (only).

Blockstream Engineering Blog

The latest developments in cutting-edge Bitcoin technology from Blockstream.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade