We’re pleased to announce lnd 0.13-beta, our second release of 2021! Building on our commitment to make the Lightning Network more reliable, robust, and secure, our latest release includes initial support for atomic multi-path payments enabling larger and more reliable spontaneous payments, a new clustered lnd operating mode, payment optimizations for robustness, and a slew of wallet enhancements to enhance security.

This release wouldn’t have been possible without the continued support from the amazing Lightning community. In this post, we’ve included a list of highlights; you can find full details in the release notes.

Introducing Atomic Multi-Path Payments

In this release, we’ve added initial support for Atomic Multi-Path Payments (AMP). AMP is the successor to the widely used “keysend” protocol as it enables payments to be sent in multiple shards similar to Multi-Path Payments (MPP). Unlike MPP, the receiver cannot pull the payment until all the payment shards arrive. This trait makes the new payment type more useful for payment-splitting aware probing.

In addition to providing a new first-class method for spontaneous payments, AMP also allows invoices to be effectively re-used. AMP invoices look just like normal invoices, however they signal that the invoice must be paid using the AMP protocol.

Receiving/Sending Spontaneous Payments

Receiving: To automatically accept incoming spontaneous AMP payments, users simply need to set a configuration option (accept-amp=1). Users can also accept one-time payments to an AMP Invoice without the configuration option.

Sending: Sending a spontaneous AMP payment requires specifying the amount and pubkey of the destination in addition to the --amp flag on the command line. Users of the RPC interface will need to set the corresponding field within the SendPaymentV2 request. Note that without specifying any routing/hop hints, this will only work for nodes in the public channel graph.

AMP Invoices

An AMP invoice for a spontaneous payment seems counterintuitive at first, however this will unlock recurring payments (eg. subscriptions, deposits/withdrawals, etc)!

Recurring invoices are not implemented in this release, but will be available at a later point. For now an AMP invoice can only be settled by one payment. That said, this release does include support for simulating recurring payments, making the existing AMP invoices "pseudo-reusable" by allowing users to specify a new random payment address. The default expiry for AMP invoices is 30 days.

Payment Optimizations

MPP/AMP Payment Splitting on by Default

Payment splitting was previously made available on an opt-in basis. In this version of lnd, MPP/AMP payment splitting is now activated by default. The default number of attempted splits is 16 and it’s also possible to specify the size of the largest split. This can be used to force a maximum payment size leading to more frequent payment splitting.

Strict Zombie Pruning

Typically lnd will mark a channel as a zombie when both of its edges aren't re-advertised within a two week period. This is typically referred to as a channel's heartbeat update. Analysis by Conner Fromknecht demonstrated that the channel graph itself could be shrunk by ~20% if a stricter pruning heuristic was adopted: pruning a channel once only a single edge fails the heartbeat check. The latest version implements this stricter pruning alternative in an opt-in manner.

Default Anchor Output Channels

The spec compliant anchor channel format was introduced in v0.12. In v0.13, if both nodes support it, the anchor channel format is the default channel type. Anchor channels are a safer and more reliable channel type as they allow for fee bumping the commitment transaction in the event a channel is force closed. They take away the up-front guesswork of determining what the proper on-chain fees will be, as they allow a node to dynamically increase the fee of a pending commitment transaction using Child Pays for Parent (CPFP).

Since a node with anchor channels must keep on-chain funds around in case unilateral fee bumping is needed, we reserve 10k sats per channel for this purpose. In this release, we cap this hold at 100k sats and avoid reserving this value for private channels.

Wallet Enhancements

We’re working hard to enable future versions of lnd to operate without access to private keys within its process.

Full PSBT Role Capability

The wallet is now able to import BIP-0049 and BIP-0084 accounts/public keys as watch-only through xpubs! This feature was made possible by the introduction of watch-only accounts to btcwallet, our internal wallet. This means that all on-chain funds can now be kept cold and PSBT support can be leveraged to create new transactions that can then be sent to the cold signer.

Events (deposits/spends) for imported keys or keys derived from an imported account will only be detected by lnd if they occur after the import. Rescans to detect past events will be supported in a future release, so, for now, the feature should be leveraged with new wallets.

Auto-unlock

We’ve noticed that many users are running custom scripts to automatically unlock the wallet. Unlocking the wallet programmatically presents a series of challenges however. To address these challenges, we’ve introduced a new flag, wallet-unlock-password-file, that can be used to auto-unlock an existing wallet from a file.

New Coin Selection Algorithm

Currently, the internal wallet uses a coin selection algorithm that prioritizes the largest unspent transaction outputs (UTXOs) when crafting a transaction. This can lead to a suboptimal wallet state with many small, uneconomical UTXOs. We’ve added a new flag, coin-selection-strategy, that can be set to random to enable random coin selection leading to less UTXO fragmentation over time.

RPC Updates

Unifying WalletUnlocker and Lightning services

This release brings a massive overhaul to the way the wallet is unlocked on the backend, while remaining backwards compatible.

In lnd v0.13.0, the two gRPC services (and subserver services) are available at all times. The RPC endpoints are gated by the wallet state (see below) such that only RPCs from the WalletUnlocker service are available as long as the wallet remains locked.

If you relied on the RPC errors or availability of the different services to determine the wallet state, you should change to use the new State service.

New State Service

A new service is now exposed on the lnd gRPC server: State. This can be used to get the state of the wallet at all times, and should be used to programmatically drive the unlocking process and to implement health checking services.

Mission Control

An experimental API has been added to allow nodes to import state from other lnd nodes. This allows new nodes to start with a "hot" pathfinding cache, which will reduce pathfinding attempts as it inherits "pathfinding memory" (set of probability weights) from an existing node. This imported information is not currently persisted however. Note that sharing state with another party may leak information about your payment history!

Bi-directional Stream Support for REST/WebSockets

All RPCs can now be used over REST/WebSockets, including the client-streaming ones (specifically lnrpc.Lightning.ChannelAcceptor, lnrpc.Lightning.SendPayment and routerrpc.Router.HtlcInterceptor). An example for using the channel acceptor over REST was also added to the documentation.

WalletKit & Wallet-Related RPCs

LeaseOutput has been extended to allow custom lease expirations and a new ListLeases RPC has been added to allow users to determine which outputs are currently being leased and for how long.

As part of our watch-only key import efforts, three new RPCs have been added to the WalletKit sub-server. Several existing RPCs were also modified (maintaining backwards-compatibility) to either accept an account parameter in their requests or break down their responses by accounts.

Longer Default Invoice Expiries

Over the past few months, we've heard from multiple sources that the default invoice expiries are too short. As a result, the default expiry for MPP invoices has been raised from one hour to one day.

Backend Enhancements & Optimizations

First-Class Support for Pruned bitcoind backends

lnd now supports connecting to pruned bitcoind backends! A new sub-system has been introduced that maintains connections to bitcoin peers to retrieve pruned blocks and caches them. These peers are sourced from the peer list of the connected bitcoind instance or from the getnodeaddress RPC otherwise. The number of connections (4 by default) can be configured through the new config option bitcoind.pruned-node-max-peers.

Clustered Configuration

We’ve heard from many customers a desire to provide highly available lightning services. With this release, we’ve added experimental support for leader elected lnd cluster, where apart from the graph, all important states reside in a replicated etcd database. This allows us to use etcd's leader election facilities to form a cluster of multiple lnd nodes, where one acts as the primary node accessing the DB, while the remaining wait to replace the leader if a failover occurs (eg. primary is decommissioned, crash, network partition, etc). With this configuration, all the nodes in the cluster share the same identity, but only the active leader has full control while the rest are dormant.

Apple Silicon (M1) Architecture Support

This is the first release that includes binaries for the recently released Apple Silicon (M1) architecture!

Mobile

We’ve introduced a number of improvements to improve reliability and performance on resource-constrained devices. This includes delaying zombie pruning on startup, enabling a graceful exit in the event lnd fails to start, as well as a handful of Neutrino optimizations.

Neutrino Optimizations

Neutrino is a Bitcoin light client designed with mobile Lightning Network clients in mind. It allows non-custodial Lightning wallets to verify transactions privately and trustlessly. In this release, we made a handful of optimizations to the light client.

Reduced Memory Footprint

The memory footprint used throughout the initial block header sync has been reduced by 50% significantly reducing the onboarding time for new users.

Configuration Options

A few new configuration options were introduced. Users can now specify how long they wish their broadcast attempts to last before giving up, compact filters retrieved from the network can be persisted resulting in less bandwidth consumption at the expense of storage, and channel validation can be activated with a simple configuration change. Check out the release notes to learn more.

Conclusion

We’ve introduced a number of improvements in v0.13 to make developing on the Lightning Network easier than ever and are committed to continuing work in this area.

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, or subscribe to our newsletter!