The c-lightning team is excited to announce the v0.10.0 release of c-lightning. This is a major release that consolidates improvements made in recent releases and enables most experimental features to be enabled at runtime.

Since 0.9.3, we’ve had 339 commits from 14 different authors, not counting all the hours of work going into plugins and apps using c-lightning.

Dual Funding Is Finally Here

Over two years since first proposed, and over a year since

neiL saitug began coding, an experimental draft of dual funding is available for the #reckless. If both sides support it, the new transaction construction protocol will be used to open channels: instead of one side creating (and funding) the transaction used to open the channel, both sides can contribute. This means that both sides might add funds to the channel, or simply use it to merge or create other outputs: it can operate as a simple CoinJoin between the peers as well.

For the moment, contributing to an incoming dual-funded open requires a plugin to offer the inputs and outputs: without that assistance, c-lightning will not add any inputs or outputs of its own.

In addition, this protocol can be repeated to replace-by-fee the opening transaction; useful if you lowballed the fee and then got impatient.

Note: the specification for this feature is not finalized, so incompatible changes may well be introduced as other implementations arrive and refine it. But it’s there today if you want to test c-lightning nodes: just turn on the new experimental-dual-funding flag in your configuration.

Sharp Edges Removed from Complex Funding

If you wanted to use an external funding source, such as a hardware wallet, c-lightning has a great API (since mid-2019!): fundchannel_start followed by fundchannel_cancel or fundchannel_complete. fundchannel_complete didn’t require the caller to give the full transaction it would use to fund the channel, just the transaction id and output number.

This was a mistake! If you get the fundchannel_complete parameters wrong, c-lightning has no way of knowing. It will tell the peer, get the first commitment transaction signature, and return success. But that first commitment transaction is wrong, so you have no way of retrieving your funds! We had a great bug report about this exact scenario, which made us sad.

We fixed this in three ways:

1. We have a new experimental-shutdown-wrong-funding option, which lets the peer tell us this happened, and we will allow them to close with a replacement transaction as long as the channel hasn’t been used.
2. We changed fundchannel_complete to take a Partially Signed Bitcoin Transaction, which c-lightning checks for validity and figures out the transaction id and output number itself.
3. Dual funding isn’t prone to this mistake since both peers cooperate in transaction construction. When this becomes the norm, this makes the problem far less likely.

In addition, Christian Decker started a detailed discussion on how we could have a standard response to these problems.

A Nasty Old Bug Gets Nicely Squished

c-lightning keeps a record of all the current gossip in a simple file called the “gossip_store”. The first byte of this is a version number: at startup, if it’s wrong (or the file is otherwise corrupt), we simply clear it and start downloading fresh gossip from our peers.

A few users have seen corruption in this file, but it hasn’t had a major effect until recent versions: the pay plugin now also reads this file to map the network and gets very upset if it’s corrupt. And for at least two users, it always seemed to be getting corrupt.

Enter Matt Whitlock, who finally tracked down what was happening to him. If the version number was wrong, we indeed truncated the file and wrote a new version byte, but it turns out we were writing it in the wrong place, leaving the version number invalid for next time! His single line fix is incorporated in this release, so this will never happen again.

Join Our Development Efforts

So there you have it, loads of new functionality to tinker with. We’d love to hear from you about what could be improved or your ideas on what could be built on top of the new features.

If you’re as excited about the new possibilities as we are, feel free to join us on IRC #c-lightning on Freenode or our biweekly developer meeting on Jitsi. If you’re curious about what we’re currently working on, we’re keeping a shortlist of priorities on the wiki.

Note: This blog was originally posted at https://medium.com/p/88556f5f964e