Announcing lnd 0.12-beta: Improving the LND Developer Experience
We’re pleased to announce
lnd 0.12-beta, our first release of 2021! One of our major goals this year is to make it easier for developers to build on Lightning, and to that end, we recently shipped new lnd developer docs. We’re also committed to making the Lightning Network more reliable, robust, and secure, and our latest release does just that:
lnd v0.12 includes anchor channels for improved reliability, faster startup times for improved robustness, additional support for Partially Signed Bitcoin Transactions (PSBTs) for improved security, and a new default Autopilot heuristic for improved resiliency of the network.
This release wouldn’t have been possible without the tremendous support of the community. In this post, we’ve included a list of the highlights below, and you can read the full details in the release notes.
Introducing Anchor Channels
With the recent rise in the price of bitcoin, we may see a future of increasing or volatile on-chain fees. Anchor output-based channels 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). The latest version of
lnd now allows users to opt into using the latest version of anchor channels between peers that support it. Anchor channels, which have been available to advanced users since
lnd v0.10, 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 (e.g. because the other party has become unresponsive).
Each time the balance is updated within a payment channel, a new commitment transaction is signed by both parties. This transaction is only broadcast if one party decides to close the channel unilaterally. However, in cases where a channel may have been open for a long period of time, fee estimation initially may result in the underpayment or overpayment of transaction fees.
The introduction of anchor channels not only increases reliability and introduces fee savings but also helps increase channel capacities by reducing the required commitment fee reserve. Note that in order to take advantage of this new, safer and potentially lower cost type of Lighting channel, new channels will need to be opened.
In the near future, we hope to deploy a new extension to the Lightning protocol spec that allows channels to be dynamically updated on the fly without any additional on-chain costs. Such a decoupled, desynchronized update mechanism for the Lightning Network will allow
lnd to automatically update users to the latest channel format.
Safer Defaults for Payments & New Channels
The Lightning Network is highly extensible with support for rolling out features in both a forwards and backwards compatible manner. As new features are introduced, nodes determine whether or not to support a feature by specifying whether the feature is required or optional. By flipping a previously optional feature to required, we can safely upgrade the functionality and security of the entire network. This new version of
lnd changes payment addresses and static remote key channels features from optional to required.
Payment addresses were introduced with the Multi-Path Payments (MPP) protocol feature. In the context of MPP, they allow a receiver to correlate disparate payment shards as part of a single payment. They also improve end-to-end security of payments by having the sender include a random secret that’s only known to the receiver in the final payload.
Channels that use a static key for the commitment output of the remote party make disaster recovery of channels easier; in the event a channel is closed by a remote party, the funds will go directly to the wallet of the other party.
The immediate implication of these changes is that
lnd may refuse to open the legacy channel type with older nodes and reject payments that don’t include the end-to-end payment secret, as both are less secure. As the leading implementation,
lnd is committed to ensuring our users adopt safe, modernized defaults to promote network safety.
Improved Operational Security & Reliability
In this new version of lnd, we’ve made strides towards making
lnd more reliable by improving the robustness of our initial solution for replicated data storage for
etcd. The new
etcd database backend now passes all existing integration and unit tests that our default database, boltdb, does. With this new milestone under our belt, we aim to make the new backend system more production ready, targeting
lnd 0.13 as its ready-for-production debut.
In addition, we’ve extended the Channel Acceptor API to allow users to be more selective about the set of channels they accept, as well as bind cooperative closure addresses to pre-configured cold addresses in order to improve operational security.
To improve the security of our credentials-based authorization system, we’ve added the ability to revoke or rotate existing macaroons generated by the macaroon bakery. If a node operator detects that any of its custom generated macaroons have been compromised, they can now automatically refresh credentials with a single command.
Finally, we’ve made
lnd more aware of its critical dependencies (disk access, chain access, etc.) by adding a series of new “health checks” that will continually run to ensure that
lnd is able to carry out its duties safely. If any of these health checks fail, then
lnd will begin a graceful shutdown, either to be manually intervened upon by a user, or automatically restarted by a hypervisor if the location/name of one of its resources has changed.
Improved Loading Times
We’ve been working hard to make it easier than ever for developers to get up and running with
lnd. A big step in this direction has been to minimize the resource requirements of
lnd. This not only helps ensure that
lnd can be run on resource constrained devices (such as Raspberry Pis) but also reduces the cost of running an
lnd node making the Lightning Network not only more accessible, but also more resilient.
Speeding up Graph Sync & Node Startup Times
In an effort to make onboarding onto the network as frictionless as possible we’ve made improvements to graph sync resulting in a 3x speed increase based on initial benchmarks. This was accomplished by batching all insertion operations related to the channel graph. These improvements may be especially apparent on mobile and other constrained platforms.
As the network matures, users of
lnd are pushing the limits of the daemon, uncovering areas that are ripe for optimization to keep up with increased user and payment growth. Users of
lnd that run larger nodes with hundreds of channels may have noticed that over time, their node has been taking longer to start up. With this latest version of
lnd, we’ve optimized the startup time for larger nodes by batching more of the sanity and consistency checks run on channels at startup to ensure
lnd is able to properly manage its set of pending and active channels. Those running larger nodes should see a significant reduction in disk and CPU utilization when standing up their nodes.
Minimizing Resource Consumption
To help minimize resource consumption we’ve added the ability to opt-in to automatic database compaction for the channel database. A bloated channel database not only takes up a significant amount of disk space, but also slows startup time. With automatic database compaction, we not only free up disk space, but also defragment and validate the integrity of the data each time compaction occurs.
Networking bandwidth is a scarce resource to be preserved when participating in decentralized peer-to-peer networks, such as the Lighting Network. As the network has grown over the past few years, the network bandwidth burden for well connected nodes has increased disproportionately. In this new version of
lnd, we’ve implemented a series of optimizations to throttle the rate of gossip activity flowing into and out of
lnd, resulting in dramatically lower CPU, disk, and network utilization for nodes across the network. These optimizations will serve to greatly reduce the idle system utilization of a given
lnd node, particularly on more resource constrained devices such as Raspberry Pis.
Towards a More Resilient Network
We’re continually looking for ways to improve the resiliency of the Lightning Network. Autopilot, which automates the process of onboarding onto the network, previously used a preferential attachment mechanism as the default heuristic for connecting to the network.
In the latest release of
lnd we’ve upgraded the default heuristic for Autopilot, now optimizing for the betweenness centrality of the node. This means
lnd will attempt to connect to the nodes that frequently appear in the shortest paths within the Lightning Network instead of connecting to nodes with the most channels.
New Generalized PSBT Capabilities Towards Cold Key
In prior versions of
lnd, we added support for Partially Signed Bitcoin Transactions (PSBTs) to make it possible to fund channels directly from an air-gapped hardware wallet or other form of segregated signer. In this version, we’ve further augmented
lnd’s PSBT capabilities to allow users to craft and sign/finalize arbitrary PSBTs funded by the internal
lnd wallet. Combined with
lnd’s set of custom concurrent safe coin selection APIs, users can now use
lnd as the basis of more advanced multi-party signing protocols that utilize PSBTs.
In the near future, we aim to further build upon this new base by extending
lnd’s internal wallet (btcwallet) with the capabilities to import arbitrary public keys and extended public keys (xpubs). Once finalized, this will allow
lnd to serve as a watch-only wallet, and also take on more of the roles in a PSBT-based workflow by being able to fully populate a PSBT instance, export to an external system for signing, and finally finalize the PSBT by producing a valid, fully signed transaction. Once complete, these capabilities will allow
lnd to function in a “cold key” manner, serving to minimize, and potentially eliminate, the amount of funds that are explicitly hot within an active instance. As we begin to onboard more exchanges and existing Bitcoin companies seeking to execute larger payment flows within the network, we’re committed to ensuring that
lnd continues to exceed the security requirements of our users.
Those interested in the details can take a look at this example of Partially Signed Bitcoin Transactions being used with
lnd and bitcoind.
Fully Verifiable & Deterministic Automated Builds Featuring Docker
As recent events have shown the critical importance of the software supply chain, we’ve made it easier for any third-party to reproduce and validate our deterministic builds. With our new and improved build system, users on both Linux and MacOS are able to verify every single binary created by our build system for proper reproducibility. In addition to this, we’ve worked to remove direct reliance on roasbeef’s GPG signature in the build system. As even the compressed archives of our build system are reproducible, any developer that is active within the project can now upload their own independent signature, serving to build upon prior signatures and “bless” the sanctity of a new
lnd release. In order to make this process easier, we’ve added new verification scripts that can be run by an end user with only Docker installed.
We are now also automatically building and pushing Docker images of all our releases to Docker Hub, thanks to the power of GitHub Workflows. All published releases will now automatically be published to our Docker Hub account as valid images. We’ve also augmented our uploaded images by allowing them to optionally verify the hash of the binary generated during the build process to match the “official” hash generated by the set of
lnd developers. This serves as defense in depth to ensure that users building their own version of
lnd produce the exact same binary as all other Lightning users and developers around the world.
Improved Developer Documentation
We recently published a new set of developer docs to make getting started with
lnd easier than ever. These documents include tutorials for integrating Lightning, guides for running LiT, best practices, and more. Stay tuned for more resources coming soon.
We’ve introduced a number of improvements in 0.12 to make it easier than ever for developers to get up and running with
lnd and we are committed to continuing this trend. Developments such as anchor channels are a big step towards a safer and more reliable network.
We anticipate that 2021 will be a momentous year for developers building on Lightning, so we're especially excited to be starting it off right with this release. If you haven’t already, please join the
lnd Slack, reach out to us on Twitter, or subscribe to our newsletter!