lightning network
Announcing c-lightning 0.7, Now With More Plugins
March 01, 2019
|
,

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

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:

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.