New Release: c-lightning 0.7.1
By Lisa Neigut & Christian Decker
The c-lightning team is proud to announce the v0.7.1 release of c-lightning. Despite it being a minor release it comes not only with a large number of bug fixes and performance improvements, but it is also packed full of new and exciting features:
- Gossip improvements: The gossip daemon is more selective about which peers it synchronizes its network topology from, considerably cutting down the time to synchronize and the bandwidth consumed by the gossip protocol.
- Longer default invoice timeouts: The default timeout for invoices is now seven days, a change from the previous value of one hour.
- More powerful plugin hooks: with the addition of
invoice_paymenthooks, this version of c-lightning provides the greatest ability to plugin developers yet.
- External-wallet channel funding: a few new RPC’s that provide the ability for external wallets to fund channels through a c-lightning node. This relaxes the need to move funds to the internal wallet to open a channel. Note that close channel funds are still routed back to the internal wallet, presently.
- More permissible for peer errors: c-lightning is now more permissive in what it accepts from its peers, and will not return errors when the peers sends messages in the incorrect order anymore.
- And as always: performance, performance, performance.
New, Powerful Plugin Hooks
This release of c-lightning brings powerful new hooks to plugin developers. This new set of hooks opens up c-lightning for best-in class backup facilities, provides a wider range of flexibility for invoice and HTLC fulfillment logic.
db_write: A synchronous plugin hook that is called whenever a change is about to be committed to the database. This is useful for creating a backup of node state in real time.
invoice_payment: This hook is called whenever a valid payment for an unpaid invoice has arrived. It allows a node to verify that it can still fulfill the invoice before accepting the payment. This hook is analogous to lnd’s hodl invoice facility.
htlc_accepted: This hook is called every time an HTLC is offered to this c-lightning node. It offers an opportunity to programmatically fail or resolve an offered HTLC, or to continue with normal HTLC processing. This hook is useful for delegating
htlc-fulfillmentto a remote node or facilitating more complex cross-chain payments.
openchannel: This hook is called whenever a remote peer tries to fund a channel to us. A plugin may either reject the
openchannelrequest with an error message for the peer, or continue as normal.
This is officially the best hook-set that c-lightning has ever offered, and we’re excited to see what new plugins are built on top of these new primitives. For more details on the specifics of these hooks, please see the plugin developer docs.
In addition to an expanded plugin hook set, 0.7.1 now includes a default plugin directory,
lightning_dir/plugins. Plugins added to this directory will be automatically loaded at node start.
Are you a plugin developer? Don’t forget to submit your plugin to the c-lightning plugin repository on Github.
Gossip Improvements via the Million Channels Project
The largest performance improvements for c-lightning were driven by work on the Million Channels Project, spearheaded by Joe Netti and Rusty Russell. A short overview of changes include:
- Reducing the in-memory footprint required for routing payments: c-lightning’s custom Bellman-Ford-Gibson routing implementation has been replaced with Djikstra, which has a smaller in-memory footprint.
- Gossip caches moved to disk: we’ve removed all of the in memory caches of gossip, except what’s needed for the routing table.
- Channels stream gossip directly from the gossip store: prior to 0.7.1 any request for gossip from a peer would be handled by
channelddaemons can directly access the gossip store file, speeding up gossip syncs for remote peers.
More details on the Million Channels Project are coming in a dedicated article very soon, so watch this space!
On the compatibility front, c-lightning now supports the
upfront_shutdown_script option, which allows closing a channel to an external wallet, and doesn’t get upset anymore when other implementations send messages in incorrect order.
The counterpart to the
upfront_shutdown_script option, is the ability to fund a wallet from an external wallet using the
fundchannel_cancel JSON RPC methods.
Without these features the user would have to first send funds into the c-lightning internal wallet, incurring in an extra on-chain transaction, before being able to fund a channel. And when closing a channel an on-chain transaction would be required to move the funds back to the external wallet.
For example, with these new features it becomes much easier to fund a channel from a hardware wallet and then move the funds back to the hardware wallet once the channel closes.