Announcing lnd 0.13-beta: Get Amped on Lightning!
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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
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
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!
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 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.
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.
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!