Announcing lnd v0.10-beta!
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.
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
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.
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.
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.
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
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.
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
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.