We at Lightning Labs hope that everyone is staying in good health. We’re grateful that the Lightning and Bitcoin communities live online in a way that allows us to continue contributing and building remotely. Today we’re excited to release the latest culmination of that worldwide effort, lnd v0.10-beta! As always, we’ve included a brief list of the highlights below, with more information included in the release notes.

Multi-Path Payments

When we released lnd v0.9-beta back in January 2020, we included support for receiving Multi-Path Payments (MPP). For newer readers, MPP allows for larger-sized payments as well as potentially more efficient payment routing. With the release of v0.9-beta, there was a conspicuous absence of the ability to send a multi-path payment. Sending has now been included in lnd v0.10-beta, along with required changes to lnd’s database and the way that lnd keeps track of payments throughout their lifecycles. In order to send using MPP, the max_parts setting should be configured to be greater than the default of one. We’re also working on a more detailed blog post about MPP to be released soon.

A related change is the lifting of the maximum invoice size, which was previously 4.2 million satoshis (0.042 BTC). Starting with lnd v0.10-beta, payments up to the maximum size of a channel will be allowed. (Currently, the maximum channel size is 16.7 million satoshis (0.167 BTC.)

Partially-Signed Bitcoin Transaction (PSBT) support

In prior versions of lnd, BTC had to be first moved into lnd’s wallet before payment channels could be opened. With lnd v0.10-beta, we’ve added the ability to fund new channels with Partially-Signed Bitcoin Transactions(PSBT). One advantage of this new PSBT support is that Lightning channels can now be funded directly from hardware wallets or any external wallet that understands the PSBT format (Electrum, etc). Another possible usage is for multiple channels to be funded from a single transaction. Those interested in the details can take a look at this example of PSBT being used with lnd and bitcoind.

On-chain fees, new Anchor Commitment Format

With the original Lightning protocol, one of the challenges was that the fee amount to be used for force closing a channel on-chain had to be negotiated and agreed upon ahead of time. Throughout most of the lifetime of Lightning, this hasn’t been a problem because fees have been relatively low and predictable. However, in cases where a channel might be open for long periods of time in which fees could go up significantly, or when a channel is opened during times of volatile on-chain fees, incorrect fee estimation or prediction could make emergency channel closing unreliable.

To prepare for a possible future with increasing on-chain fees or more volatile on-chain fees, lnd v0.10-beta introduces a new Anchor Commitment Format. This new format uses “anchor outputs” which allow for fees to be specified (technically, bumped) after a channel close transaction has been broadcast. This new anchor commitment format should enable fee savings as well as more reliable channel closes. Note that this feature is still in the experimental stages and the spec isn’t yet finalized. To use this new commitment format, start lnd with the --protocol.anchors flag and open a channel to another node that also supports the format.

On a somewhat related note, lnd now also supports bitcoind’s fee estimation modifiers.

Developer improvements

In our discussions with community members, one of the themes has been a request for more detailed information about payments in progress. In lnd v0.10-beta we’ve addressed some of this feedback, with more fine-grained payment status updates as well as error messages for failed HTLCs.

For developers, there were also a number of smaller RPC and lncli changes to make working with lnd v0.10-beta a bit simpler and more convenient.

Finally, in lnd v0.10-beta, we’ve added an “Experimental Services” section to the lnd gRPC API. These services are designed to allow lnd developers to experiment with and give feedback on new APIs while they’re in the process of being developed. This will also give new features and APIs a place where they can be tested, stabilized, and matured before being added to the main lnd API. For REST developers, we’ve also made the REST API docs more easily accessible.

Architectural improvements

In order to make lnd nodes more robust to hardware or network failures, we’re making database changes that will make it possible to have multiple copies of channel databases that can seamlessly resume transaction processing in case of an unexpected failure. A key first step added in lnd v0.10-beta is a database abstraction layer that makes it possible to use different databases with lnd than the default bbolt. The first new database we’re planning to support is etcd. A related change makes lnd itself more modular and more customizable by developers.

Privacy and security

In lnd v0.10-beta we’ve made it possible to deploy lnd and Tor more safely together, and we’ve also added support for deploying Watchtowers via Tor hidden service.

We’ve also added a new fuzz package for testing lnd and a new Operational Safety Guidelines document that node operators can refer to in order to help them run their nodes more securely.

Bug fixes

What would an lnd release be without a few bug fixes? In lnd v0.10-beta, channel backups are now saved earlier. Channel updates are now slightly more reliable across restarts. The REST gateway is a bit more predictable. A “dust” edge case has been fixed. A change to pathfinding scoring has been made. Finally, a log message has been fixed.

Conclusion

For all of you in the Lightning community who are continuing to test, code, operate nodes, build services, and contribute ideas, we thank you as always, and more so now when you have so many other priorities to look after. Special thanks to the testers who submitted bug reports, the contributors who submitted code, and all of those who reached out with feedback about lnd v0.10-beta!

The world has been changing at an incredible pace lately, and the course of these events may make the advantages that Lightning and Bitcoin have over the legacy system even more apparent, perhaps sooner than expected. On the other hand, we do miss seeing and hearing from members of the Lightning community in person at meetups and conferences. To fill in some of the gaps, over the coming weeks, we’ll be posting links to virtual events and we hope to engage with you all there.

Please continue to send us feedback about lnd and Lightning via Slack, Twitter, and Github as well!