Released: c-lightning 0.8.0

Includes mainnet default, multi-part payments, and extended plugin functionality

By Christian Decker

The c-lightning team is pleased to announce the release of c-lightning v0.8.0. This release is the culmination of ten months of work since our last release, by 16 contributors from all over the world and comprising 305 commits.

Some of the biggest changes coming with this release:

• Bitcoin mainnet first
• Multi-part payments support
• Extending plugin capabilities

Details of these updates are provided below.

Bitcoin Mainnet First

When we first released c-lightning we made the Bitcoin testnet the default network, due to the experimental nature of both the protocol and the implementations. After almost two years of experience on both testnet and mainnet, it is now time to fully embrace being #reckless, and make Bitcoin mainnet the default network. Starting with v0.8.0, any newly started node will run on mainnet unless you specify the --network in the command line or the configuration file.

In parallel to the change in default network, we are also taking the opportunity to better structure the data directory layout: if you ever tried to start a node with a different network you might have come across a warning about mismatching networks. This is because the data that a node stores is network-specific, and nodes on different networks need to have different data directories:

Wallet blockchain hash does not match network blockchain hash

The data directory is now split into network-specific subdirectories that isolate nodes on different networks from each other, without the need to specify --lightning-dir when starting the nodes. As part of this, lightningd will create the network subdirectory and move any existing data and configurations into that subdirectory.

Multi-Part Payments Supported

The user experience of Lightning clients is a topic that is brought up often, and we are working actively on improving the status quo, together with the teams working on other Lightning implementations. Our goal is to make using Lightning as easy as using an on-chain wallet. To reach this goal, the Lightning community is concentrating on two core improvements:

• Multi-part payments allow a Lightning node to bundle the capacity in all its channels when making a payment, making larger payments than any individual channel on its own would allow.
• Splice-in/splice-out minimizes the distinction between on-chain and off-chain funds, allowing on-chain payments to be performed from a channel and removing the need to keep two balances (one for off-chain funds and one for on-chain funds).

Multi-part payments, which we are releasing with v0.8.0, bring us one step closer to this ideal of a unified wallet experience. Sometimes called atomic multi-part payments (AMP), multi-part payments allow the sender to split a payment across an arbitrary number of channels and routes, combining liquidity in all those channels up to the desired amount. This greatly reduces the headache of managing how many channels to open, and how to allocate funds to them, since you can now simply combine them as and when necessary.

Multi-part payments also greatly increase the resilience of the Lightning Network. The capacity of the largest channel used to be the limiting factor when performing payments. As such, users were incentivised to open a single channel, with as many funds as possible, to a node that was as stable as possible. This led to users rating the reliability of nodes before opening a channel with them, since that node would now be their single point of failure, i.e., if that node was down, they couldn’t do much. With multi-part payments, users can now open multiple channels to multiple nodes, while at the same time being sure that the funds will be there when they need it. For the network, this means more connectivity and better resilience against the threat of big nodes suddenly disappearing.

At this point, we would also like to thank our friends at ACINQ who helped us to test this feature. The adoption of multi-part payments by a second independent implementation allowed us to mark this feature as “generally available” instead of an experimental feature.

Extending Plugin Capabilities

Our main goal with c-lightning is to create a Lightning Network implementation that is as flexible and lightweight as possible. This led us to introduce plugins earlier this year: a simple way for developers to extend a node’s functionality without having to leave their favorite development environment.

With 0.8.0 we continue down this path, by extending the capabilities we expose to plugins, and allowing the creation of ever more powerful extensions. In addition to the plugin db_write, htlc_accepted and invoice_payment hooks introduced in the previous releases, this release adds the rpc_command hook that allows a plugin to intercept RPC calls. This can, for example, be used to authenticate, authorize or audit RPC accesses. The htlc_accepted hook has been extended to support modern TLV style payloads, that can be used as a counterpart to sendonion (see below).

On the JSON-RPC side, we continue the work started with the getroute and sendpay, and fundchannel_* methods. Abstract RPC methods are split into multiple steps, allowing plugins to customize how those steps are combined. v0.8.0 introduces createonion and sendonion which split the sendpay command even further and enables the creation of custom routing onions. With these tools, it becomes simple to implement protocol extensions like chat messaging over the Lightning Network. At the same time, it decouples the need for c-lightning to implement many of the more experimental aspects of the protocol, and developers can start experimenting with protocol extensions much easier on their own.

Expect even more changes providing extended access to c-lightning internals in the coming months.

Looking Forward

The Lightning Network has seen a lot of growth during the past year with many things happening under the hood that may not always be visible to the casual observer. This infrastructure work has established a solid foundation on which the community can continue to build on top of. And so, while 2019 was an exciting year with many advances and amazing community growth, we look forward to an even better 2020.

The c-lightning team will be there with you, providing the best platform possible for all the applications and use-cases the community can come up with. 😉