We're excited to announce LND 0.16.0 beta, our first release of 2023. Continuing on the path to improve all things Lightning from pure technological changes to developer experience, this latest release includes:

• Revamped pathfinding logic designed to improve payment success probability

• Watchtower updates engineered to save significant disk space, improve performance, and address several bugs

• Infrastructure update to include SQLite backend as a database option for new nodes

• Multiple refinements made to RPCs to ease app development and improve user experience

We are grateful for the ongoing support from external contributors. A total of 56 developers contributed to this release -- an all time high!📈

In this post, we’re including a few release highlights, and you can check out the release notes for the full details.

Pathfinding Upgrades

Improving the reliability of payments is an ongoing theme for the Lightning Network. As the network grows and evolves, the models deployed, and assumptions made in those models, need to evolve as well. In this release, there are two major changes to the pathfinding logic in LND. These changes, outlined in detail below, are capacity dependent enhancement of success probability, which adds a probability factor based on a transaction’s capacity usage, and a bimodal estimator, which assumes liquidity is not evenly distributed within a channel. These changes will affect how the probability of success is calculated for the various paths available to route payments. With these options, users will have more flexibility and choice with regard to how pathfinding works on their node, which in the long run should lead to better pathfinding and higher payment success rates on LND.

1. Capacity-dependent enhancement of success probability

The original method LND used to calculate the likelihood of a successful transaction assumed a constant probability for untried channels, called the a priori probability. This didn't consider the channel's capacity usage. With the new approach, LND takes into account the channel's capacity usage by adjusting the a priori probability with a capacity factor, expecting a lower success rate when a channel is running low on capacity vis-a-vis the payment amount being forwarded.

The above graph displays this payment amount dependent capacity factor, for a channel with a capacity of 10M sats. The factor and thus the probability drops quickly when a threshold fraction of the channel is reached. You can see two different configurations for the fraction above:

• The line in purple shows the fraction at 75% of channel capacity, where success probability degrades at a lower payment amount
• The line in black shows full channel utilization, where success probability degrades at a comparatively higher amount

In simple terms, the larger the size of the payment compared to the channel capacity, the lower the chances of payment success. Overall, this has the effect of discarding those channels in pathfinding, to improve overall payment success.

This pathfinding model can be activated by setting routerrpc.estimator=apriori in LND’s configuration, which represents the default probability estimator. Additional controls have been added to scale the effect of the probability calculation (e.g. you can set routerrpc.apriori.capacityfraction to a value between 0.75 and 1.0, see the above figure). This value defines the fraction of channels' capacities that is considered liquid in pathfinding, setting it 1.0 will disable this feature.

2. Alternative probability estimator based on liquidity distribution

Based on empirical analysis and commonly observed user behavior, it’s our conclusion that the balance of liquidity in channels is often lopsided to either side, or bimodal. This means that liquidity on most channels is either mostly on the local side or mostly on the remote side as shown in the following graph for a channel of 10M sat.

From the conclusion above, we anticipate that channels will have liquidity either locally or remotely, within a certain scale. By integrating this observation with our probability estimation model (based on Rene Pickhardt & others' work), we introduced a new probability estimator that accounts for the uneven balance of channels and incorporates previous payment experiences in a continuous feedback process.

This model can be utilized by setting routerrpc.estimator=bimodal in the configuration. Since a bi-modal liquidity distribution on channels represents a more practical reality of the state of the network, probability calculated based on this assumption can lead to more successful payments.

Both of these models can be especially useful for node operators who handle large outgoing payment volumes. We would encourage such users to take advantage of these features to improve payment success probabilities in their operations.

The models can also be configured at run time. E.g. via lncli:

• lncli --network=testnet setmccfg --estimator=bimodal
• lncli --network=testnet setmccfg --estimator=apriori

In addition to the changes above, we are also doing A/B testing with Loop to improve path finding UX and performance. Findings will be published in future technical blog posts.

Watchtowers Run Leaner

Significant improvements, like reduced disk space usage and lower memory utilization, have been made to watchtowers with this release. These improvements enable more reliable and efficient usage of Watchtowers for any node runner. As a reminder, watchtowers help secure your channel against breaches when your node is offline. You can read more about how to run watchtowers in our Configuring Watchtowers Guide.

With the improvements to watchtowers in this release, we have seen disk space savings of up to 93% in simulations and early-tester reports. Optimizations have also been made to reduce run time memory utilization and improve performance. Another interesting feature that is now available is the ability to add/remove towers without restarting LND, which is useful for node operators who can now use watchtowers to improve security without compromising on uptime.

Now With SQLite Database Support

SQLite is a new database backend option available with this release, for users setting up new nodes. Using an SQLite database provides performance benefits such as faster startup and parallel I/O operations. This option is different from Postgres and is expected to become the default backend for LND nodes in the future. SQLite is supported on major platforms and brings LND's design closer to first-class native SQL schemas. This move will offer scalability and performance benefits required for high-volume operations. Furthermore, it enables advanced functionality for backups and database replication to multiple locations.

The SQLite option will not be available, though, for users running LND on certain platforms such as windows-arm, windows-386, linux-ppc64, linux-mips, linux-mipsle, and linux-mips64 as these platforms do not support it.

Note that this database option is currently available only for users setting up new nodes. We are planning a migration path to SQLite for existing nodes in a future release, so stay tuned.

RPC Improvements

Several changes have been made to a variety of RPCs which improves ease of development and improves the user experience:

• base_fee_msat & fee_rate_ppm options have been added to openchannel requests so that the user can specify fees at the time of opening the channel. This was a frequently requested feature
• ForwardingHistory and ListChannels now enrich their responses with the peer’s alias name if these RPCs are invoked with a new PeerAliasLookup flag. This simplifies app development by saving additional lookups to determine the alias, and is another area where we received developer feedback
• ListInvoiceRequest and ListPaymentsRequest rpc responses now include creation_date_start and creation_date_end filter fields. This can help add pagination on the UI and lower response time for data-heavy nodes.
• SendCustomMessage and SubscribeCustomMessage APIs can now be used to send and receive custom messages below the custom range if LND is built with the dev tag, and configured to opt into overriding a specific message type. This feature will enable an external application to send custom onion messages, e.g. BOLT12 onion messages via LND.
• New RPC sub server to expose chain information, which added GetBlock, GetBestBlock and GetBlockHash endpoints.
• Watch-only support for taproot public keys and tapscript-derived outputs.

LND Is Scaling 📈

We’ve introduced a number of improvements in 0.16.0 to make developing and running on the Lightning Network more scalable and less resource intensive. Since the last major release in 2022, we have made significant progress on key areas, such as pathfinding, watchtowers, and new database support. We’re excited to see the growth of this technology continue and are excited to work with the community to bring bitcoin to billions with Lightning.🌍

Thanks so much to the entire community for their feedback on and contributions to this release, and we look forward to hearing your thoughts. You can find us on the LND Slack, reach out to us on Twitter, contribute a PR, or subscribe to our newsletter. The future of Lightning is bright! 😎