Announcing c-lightning 0.7, Now With More Plugins

The c-lightning team is pleased to announce the v0.7 release of c-lightning. This release is the culmination of eight months of work since our last major release, by 50 contributors from all over the world and comprising 1,300 commits. Not only does this release include a number of performance enhancements and bugfixes, but it comes with some truly exciting new features.

New Features

• Plugins: the flagship feature for the 0.7 release, plugins allow developers to extend Lightning with their own applications written in any language. Plugins further strengthen our commitment to becoming the most flexible, extensible, and customizable implementation of the Lightning Network specification. They enable us to stay focused on the core functionality, while at the same time empowering users and developers to add their own functionality to integrate c-lightning into their environment.
• Routeboost is now implemented, allowing us to send and receive payments over non-public channels by adding their details to invoices. This is important for nodes that do not announce their channels, allowing them to keep them private.
• Improved funds management: better control over which coins are used to fund channels and withdraw from the nodes helps avoid a number of pitfalls with unconfirmed transactions.
• option_data_loss_protect is now enabled by default, bolstering both your own security against datalosses, as well as that of your peers.
• Reproducible builds: with some setup, you can build your own Ubuntu binaries and check that they’re identical to the ones we provide for your convenience.
• Better documentation: the best features are of no use if they are not well documented. For this reason we have revamped our documentation which are now automatically generated at lightning.readthedocs.io
• And, as always: performance, performance, performance.

Extensibility and Customizability through Plugins

While extensibility and customizability, along with performance and security, have always been our primary goals, until now users had to write fully-fledged daemons in order to add simple functionality or make small changes. This changes dramatically with the introduction of plugins. Plugins are simple programs, written in any language, that are managed by the c-lightning. This corresponds to the sidecar model, in which an associated process runs alongside another process it is interacting with. In addition we expose a number of extension points through the plugin API:

• Command line option passthrough allows plugins to register their own command line options that are exposed through lightningd so that only the main process needs to be configured.
• JSON-RPC command passthrough adds a way for plugins to add their own commands to the JSON-RPC interface.
• Event notifications provide plugins with a push-based notification mechanism about events from lightningd.
• Hooks are a primitive that allows plugins to be notified about internal events in lightningd and alter its behavior or inject custom behaviors.

From the JSON-RPC and option passthrough providing a single point of interaction with both the daemon and any plugins, to the notifications and hooks enabling real-time interactions or even modifications to the behavior of the node, these extension points enable a much tighter integration with the core daemon than was previously possible.

Compared to the existing ways to extend c-lightning, the requirements to get started with plugins are also far lower than ever before. If you’ve ever written from stdin, written to stdout, and handled JSON encoded data, you have all skills required to build a plugin. In addition, we and the community have built a number of libraries to facilitate writing plugins in C, Python, Golang, or Java.

The following example is a Python plugin showcasing JSON-RPC passthrough, option passthrough, and notifications for the logging of messages to c-lightning:

#!/usr/bin/env python from lightning import Plugin plugin = Plugin(autopatch=True) @plugin.method("hello") def hello(plugin, name="world"): greeting = plugin.get_option('greeting') s = '{} {}'.format(greeting, name) plugin.log(s) return s @plugin.init() def init(options, configuration, plugin): plugin.log("Plugin helloworld.py initialized") plugin.add_option('greeting', 'Hello', 'The greeting I should use.') plugin.run()

Along with the JSON-RPC interface, the plugin system is a first-class citizen among our interfaces, and we are continually extending its functionality in terms of information exposed and interactions with the c-lightning core.

New Modularization

Not only do plugins allow users to extend and customize c-lightning, they also enable us, the c-lightning developers, to better modularize c-lightning. Over the last few weeks we have been porting some of the functionality that used to be hardcoded into c-lightning itself into plugins. Moving this functionality into plugins serves two primary purposes:

1. We achieve a greater separation of concerns, by explicitly stating what information may be accessed and what actions can be performed.
2. We enable users to simply swap out the plugin with their own implementation, should the default plugin not match their requirements.

By using plugins ourselves, we also make sure that they are truly are a first-class citizen, continually upgrading their expressiveness and the way they can interact with the core daemon.

For example we have migrated some of the code relating to the payment of invoices into a pay plugin. The main purpose of the pay plugin is to receive an invoice, and then perform a payment based on the information in the invoice. While this sounds simple, it turns out that a single payment may result in a rather lengthy process of extracting additional information from the invoice, such as routehints and the soon to be implemented multi-part payments. Based on that information, the plugin generates a number of routes, attempting to route a payment over each route, and retrying should any of them be unavailable. Migrating this functionality into a plugin allowed us to write simpler code on both the plugin side as well as the core daemon. It also allows users to replace it with their own should they have a better solution to route payments, e.g. based on additional information about the state of the network, without needing us to build it into c-lightning itself.

Despite the plugin system having only recently been completed, a number of developers have already started designing and writing a number of innovative plugins, extending c-lightning’s functionality beyond what we could have imagined: autopilots, network probes, prometheus metrics, cross-chain atomic swaps, additional RPC interfaces, and many more.

Looking Forward

While certainly an important milestone for us, this release is but the start of more things to come. After recently finalizing the v1.0 of the Lightning Network specification, we are looking forward to many more exciting and innovative features on our roadmap.

For one, we recently proposed a more flexible way of constructing the onion routing packet, allowing more information to be carried to hops in a route. This will enable powerful features such as spontaneous payments that don’t require invoices, and rendezvous routing that hides both the sender and the receiver identity during a payment.

Other proposals we have been working on include dual-funded channels, for providing better liquidity to the network, and the removal of fee commitments, which solve one of the main causes for channel closures.

With the 0.7 release of c-lightning we are excited to get started with implementing these amazing features and tackle some of the big challenges that lie ahead.

We’d like to thank the many contributors who have not only contributed code to c-lightning, but also those who were #reckless enough to test and give feedback about what works and what could be improved. And finally, we’d like to thank the other Lightning Network teams, ACINQ and Lightning Labs, as well as all individual contributors that pitched in to make the Lightning Network community such a pleasant, collaborative and open environment!

Get Started with Plugins

Lightning needs more plugins! To get started extending your Lighting apps, you’ll want to first check out our documentation, then some sample plugins. We’d love to hear your feedback on the new updates. You can reach out to us via our GitHub repo or via the Lightning-dev mailing list.