Announcing lnd v0.5-beta!

Today, we’re excited to announce the latest release of lnd, v0.5-beta! The key focus for this release was to enable end-user apps (aka “light clients”) with a BIP 157/158-compliant implementation of the Neutrino protocol. In addition, we’ve made major improvements in safety and security of user funds, along with features that lay the groundwork for the next release of lnd, which will focus on routing nodes. We’ve also added another Tor privacy option, and as always, we’ve made numerous improvements to optimize performance and increase reliability. A few of the highlights are listed below, and for the full details, please see the release notes.

Neutrino support for “light client” apps

As mentioned, a key focus of this release was building the infrastructure to support high-quality end-user apps. Implementation of the BIP 157/158-compliant Neutrino protocol in lnd v0.5-beta is a major milestone in this direction. Neutrino dramatically reduces the CPU, memory, storage, and bandwidth required to use Lightning, since it’s no longer necessary to run a full Bitcoin node. On Tuesday, we released the newly-designed Lightning App (testnet alpha) built on Neutrino so that we can gather feedback from users about how best to present Lightning in an intuitive way. In addition to the core Neutrino implementation, we also worked hard to optimize blockchain syncing for light clients with a several caching and logic improvements.

Safety and privacy

Related to improving lnd’s support for end-user apps, we’ve also added a number of changes to make lnd and Lightning safer for users. One significant improvement is in “dataloss protection,” which is necessary when a device is lost or data becomes corrupted. In lnd v0.5-beta, users can now recover from certain kinds of database corruption. More importantly, some of the core code for handling recoveries is now in place, particularly the procedure for closing channels in cases of data loss. Combined with upcoming channel backup features, this will allow future versions of lnd to recover all funds in cases of total data or device loss.

Other areas where user safety has been improved are duplicate payment detection and macaroon authentication. Duplicate payment detection ensures that multiple payments with the same secret (payment hash) aren’t sent, which could otherwise lead to a loss of funds. Macaroons are encrypted tokens used for authentication and access control in lnd, and handling for those has been made more robust and secure as well.

User privacy is a major consideration in lnd, and in this release, we’ve added additional support for Tor so that Lightning users who accept inbound connection requests can avoid revealing their IP address. Previously, lnd supported outbound Tor connections, but with lnd v0.5-beta, inbound onion services (Tor v2 and v3) are supported.

Routing network improvements

In the next release of lnd, support for high-availability routing nodes will be a major theme, but in lnd v0.5-beta, we’ve added a significant amount of infrastructure to support the Lightning routing network as well.

Several changes in lnd v0.5-beta are intended to make the channel graph (an lnd node’s map of the Lightning Network) cleaner so that routing can be faster and more reliable. Previous versions of lnd would remove or “prune” channels that had not sent channel updates within the preceding two weeks. lnd v0.5-beta will also prune any nodes that don’t have active channels. lnd v0.5-beta also includes a policy for “disabling” channels, or broadcasting to the rest of the network when a channel is being closed or when a peer node has gone offline. Both of these measures should be a step forward in improving routing performance and reliability.

Another change that should also help keep the channel graph cleaner is the ability for lnd’s Autopilot function to create unadvertised channels. The recently-released Lightning App mentioned above takes advantage of this functionality. Since most users running the App won’t be routing payments, their channels need not be advertised to the rest of the network.

Two other new features (SendToRoute and Strict Local Forwarding) are relevant to routing node operators. These features provide additional control for channel rebalancing by providing node operators with direct control over how payments will be routed (rather than using lnd’s automated routing algorithms). This allows node operators to move capital to where it’s needed to support efficient and reliable routing.

Performance

Eliminating performance bottlenecks is something we’re always working on, and in lnd v0.5-beta, a number of changes were made to improve startup time. In particular, lnd now executes multiple startup tasks concurrently. Other improvements were made to reduce CPU usage more generally.

Another major improvement that was the result of a collaboration with the Lightning implementers community was an improvement to the channel graph synchronization protocol. This improvement makes the entire network more efficient by reducing the duplication of data transmitted during network synchronization.

Reliability

Last, but not least, an ongoing theme for lnd is constantly improving reliability. Unfortunately, a lot of reliability-related changes aren’t readily visible to users, but building systems that can gracefully handle losses of power or network connectivity at any time is extremely challenging. A major aspect of this in lnd v0.5-beta was making sure that data for ongoing payments was saved in such a way that payments interrupted for any reason could be recovered and resumed upon node restart.

lnd supports using btcd, bitcoind or Neutrino to provide underlying bitcoin blockchain data and connectivity, and reliability for lnd with bitcoind was significantly improved in lnd v0.5-beta. Previously, bitcoind updates about transactions could be missed by lnd, leading users to be unaware of the actual state of their funds. In lnd v0.5-beta, notifications from bitcoind are handled much more reliably.

For those users running routing nodes inside networks with Network Address Translation (NAT), lnd’s reliability has also been improved with the inclusion of NAT traversal. lnd will now attempt to use two different protocols (NAT-PMP and UPnP) in an attempt to allow inbound connections.

A series of other reliability fixes were also included in lnd v0.5-beta, including more reliable payment routing, improved fee management, and more robust APIs for monitoring payments.

Summary

While initial support for Neutrino-based Apps and “light clients” was the major theme for lnd v0.5-beta, hopefully this post also reflects some of the other improvements made in many different areas by many different contributors. These improvements set the stage for routing nodes as well as for a more generally reliable Lightning experience. We are hugely appreciative of all of the contributors to lnd v0.5-beta as well as all the testers and lnd community members who have contributed their time via IRC, Slack, GitHub, and in person. We’re humbled and inspired by the support we’ve gotten from the community and we’re excited to be delivering yet another step toward our vision of making Bitcoin and Lightning available for the entire world to use.