Note: The 0.14.1 release of LND is recommended for everyone who updated to LND 0.14.0 and it corrects a variety of issues reported by users who installed or upgraded the 0.14.0 release.

We're pleased to announce lnd 0.14 beta, our final release of 2021! Building on our commitment to make the Lightning Network more reliable, robust, and secure, our latest release includes:

• Revamped replicated storage backends + optimized etcd database support for increased redundancy in the stack

• Initial support for a Postgres replicated backend initially running in a key-value mode allowing for more efficient storage of large datasets

• Initial version of remote signing, an oft-requested feature, for enhanced security

• In-memory pathfinding resulting in 10x faster pathfinding with increased response times

• Added RPC middleware interceptor which allows developers to construct business logic for LND through the use of custom macaroons

• Reusable Lightning invoices with AMP, allowing for users to continually receive payments without regenerating a new invoice each time

This release wouldn't have been possible without tremendous community support (over 40 contributors to this release alone). In this post, we've included a list of the highlights, and you can find more details in the full release notes.

Building for Scale and Security

Given the rapid growth of the Lightning Network over the past few months, this release prioritizes adding features, enhancements and optimizations that increase scalability and security. LND's security and scalability are critical properties to an optimal infrastructure for our users. The primary new features in this release that demonstrate this priority are Postgres database support, full remote database support, in-memory pathfinding, and an initial version of remote signer capabilities.

Postgres Database Support

In this version of lnd, we've added initial Postgres database support, using it as a key-value store. Postgres has several advantages over the default bbolt backend. First, Postgres better handles larger datasets, which as the Lightning Network continues to grow, will be crucial to scaling smoothly. Additionally, Postgres has more widespread industry use and provides stronger security assurances from years of battle testing, plus on-the-fly database compaction to decrease maintenance requirements. LND's initial method for data storage will use Postgres as a key-value store but in the future, native Postgres tables will be phased in to handle heavily loaded data segments -- like invoices and payments.

Full Remote Database Support

The latest version of LND now stores all of its data in the same remote database, such as etcd, instead of just the channel state and wallet data. Compared to prior versions that had stored certain state-like wallet information locally, this change makes lnd fully stateless allowing for users running lnd (at scale) with multiple nodes to switch over to a new leader node, the only node able to read and mutate the database, almost instantaneously. This change should make running multiple lnd nodes at scale a smoother experience with less downtime. This feature also enables high-availability designs to run LND at larger scale.

In-Memory Pathfinding

Pathfinding has been a costly read-write operation to perform -- especially given all the new nodes to route with -- but no more! Keeping a copy of the channel graph in memory turbo charges pathfinding while reducing IOPS (input output operations per second) load for infrastructure-engineers' bottom line. In preliminary tests, we've seen as high as a 10x path finding attempt speed up, which should translate to lower perceived payment latencies across the network. This feature uses more RAM so low-memory systems are advised to run with the routing.strictgraphpruning=true configuration option. This flag more aggressively removes zombie channels from the graph, reducing the number of channels that need to be kept in memory. For mobile nodes, this can be disabled with the flag --db.no-graph-cache=true.

Remote Signing for a More Secure Lightning Node

Fans of "defense in depth", an information security concept based on layers, now have another tool to harden their infrastructure with: remote signing functionality. Remote signing refers to a mode of lnd where the wallet is segregated into two parts. One instance is running in watch-only mode -- with its wallet holding only public keys. The second instance manages the corresponding private keys.

The advantage of such a setup is that the lnd instance containing the private keys (the "signer") can be completely offline except for a single inbound gRPC connection and the outbound connection to bitcoind, btcd, or neutrino. The signer instance can run on a different machine with more tightly locked down network security, optimally only allowing the single gRPC connection from the outside. With this setup, system administrators can lock down the node and isolate access to sensitive key material.

With this functionality, which has been requested by many users, this version of lnd can be more secure due to less hot wallet risk. Furthermore, this is just the initial initial version of remote signing in lnd. Future versions will have a slimmer binary and eventually implement more validation.

Improved Connectivity

Bridging the Network with Hybrid Tor Connectivity

In this version of lnd, users can choose to enable a hybrid Tor connectivity mode, where Tor is only used for connections to Tor-only nodes, and clearnet for everything else. This will help improve network connectivity as a larger proportion of Lightning nodes are Tor. This new behavior can be added using the tor.skip-proxy-for-clearnet-targets flag.

Automated Tor Health Checks

Further, a new health check, Tor connection, is added to lnd's liveness monitor upon startup. This check will ensure the liveness of the connection between the Tor daemon and lnd's Tor controller. This feature will help to fix issues where the tor daemon restarting lead to destabilized peering.

Channel and Payment Improvements

Batched Channel Funding

In this version of lnd, multiple channels can now be opened in a single transaction in a safer and more straightforward way. This option is accessible through the BatchOpenChannel RPC as well as lncli batchopenchannel. With this option, users can save on fees by amortizing the cost of opening multiple channels across a single batch.

Explicit Channel Negotiation

This new protocol extension, called explicit channel negotiation, allows a channel initiator to signal their desired channel type to use with a remote peer. If the remote peer supports the channel type and agrees, the previous implicit negotiation, based on the shared set of feature bits, is bypassed, and the proposed channel type is used. This change paves the way for more advanced channel types, particularly those that leverage advanced taproot features.

Reusable Static AMP Invoices

AMP invoices are now fully re-usable, meaning it's possible for an lnd node to pay a static AMP invoice multiple times. AMP, Atomic Multi-path Payments, Invoices are the successor to the widely used "keysend" protocol as it enables payments to be sent in multiple shards similar to Multi-Path Payments (MPP). From a user perspective, this functionality gives the ability to create one invoice that can be used repeatedly so that developers can create subscription-like features.

An AMP invoice can be created by adding the --amp flag to lncli addinvoice. From there, repeated payments can be made to the invoice using lncli payinvoice. On the receiver side, notifications will still come in as normal, but notifying only the new "sub-invoice" paid each time.

Compared to approaches that require nodes to continually fetch new invoices from a server/node, reusable AMP invoices allow applications and wallets to fetch a single (somewhat long lived invoice) that can be used for repeated payments. In addition, the AMP invoice format (which specifies a new payment type) is compatible with the currently deployed invoice negotiation protocols (such as Offers, LNURL, LN Address, etc), as they can be used to fetch an AMP invoice for storage by the client. On the API level, in addition to the normal payment_hash value we all know and love, reusable AMP invoices introduce two new fields to eventually replace the payment hash from an accounting Pov: the payment_addr and set_id (both 32 byte values). Each AMP invoice is generated with a fresh payment_addr that can be used to look up all the past payment repeated payments to the same invoice. Each time a user attempts a new payment, they generate a new set_id to associate with the existing payment_addr. In this new operating mode, the two tuples of (payment_addr, set_id) are enough to uniquely identify a given payment.

The initial implementation from an API perspective has been made with the goal of minimizing the set of changes for applications and services that already accept payments on Lightning. Future iterations will evolve to create a more first-class API for subscription and recurring payments with input from the developer and wallet community. Similar to keysend (which AMP supersedes), users will need to opt into being able to receive these new payments with the --accept-amp flag. In addition, we plan to finalize our AMP specification, so the new payment type can be deeply integrated into other implementations and wallets.

Unlocking Functionality with Macaroons

Macaroon-Based Middleware Interceptor

0.14 introduces a new middleware interceptor for macaroons. This mechanism is similar to existing channel or HTLC interceptors, but for the gRPC messages themselves. With this new system, developers can implement custom business logic outside of lnd itself. In order to ensure the security of this new layer, we bind everything to macaroons with custom caveat conditions. Only client requests with the attached custom caveat macaroon will even be given to the middleware for inspection.

The inclusion of the macaroon interceptor serves to fully unleash the potential of macaroons as an access control and Lightning application primitive. The interceptor allows the creation and validation of nearly arbitrary policies such as "Bob can make payments on Tuesdays, but only up to 100k satoshis". In addition to being able to accept/deny requests based on these custom macaroons, the middleware also allows modifying the responses as well. This feature can be used to implement scoped wallets, where a user only sees their available balance from the WalletBalance call, though the wallet as a whole may hold more funds. Such policies can be used to implement fire-walled multi-user community wallets, downtime detection services, and much more.

Conclusion: Lightning Go Up!

We've introduced a number of improvements in v0.14-beta to make developing on the Lightning Network safer, more secure, connected, and scalable than ever. Since 0.13, we've made immense progress on these key areas through the features outlined in depth above. We're excited to see this technology deployed in the wild by our users around the world.

With all the recent developments this year we're excited to be contributing to the continued growth of the Lightning Network with this release. If you haven't already, please join the lnd Slack, reach out to us on Twitter, contribute a PR, or subscribe to our newsletter!