Announcing lnd v0.8.0-beta!
The Lightning Conference in Berlin is just around the corner, and to make things a little more exciting for conference attendees (and for everyone else, really), today we’re announcing the release of
lnd v0.8.0-beta! With more users and more businesses joining the growing Network every day, in
lnd v0.8.0-beta we’ve focused on additional safety features, improved routing, and more complete support for
lnd-based apps and wallets targeted at mobile devices. As always, there were numerous smaller improvements and bug fixes by many contributors along the way as well.
A major protocol improvement in `lnd v0.8.0-beta` is the introduction of a feature dubbed “SAFU Commitments.” With the pre-`v0.8.0-beta` implementation of payment channels, funds from force closed channels were sent to keys that were not directly derived from the user’s seed, as there was an additional piece of data called a “`commitPoint`”, that was also necessary to claim funds. This introduced a strong dependency on channel counterparties in data loss recovery situations. With SAFU Commitments, successful recovery with a Static Channel Backup (SCB) is no longer dependent on a channel counterparty being online and willing to provide the latest `commitPoint`. Thus, funds recovery with SAFU Commitments should be simpler and more reliable, as the only requirement is for the channel counterparty to force close the channel (eventually or upon request). Note that SAFU commitments are only used for new channels that are created between parties support SAFU Commitments (which is now default in `lnd v0.8.0-beta`).
Another safety improvement in `lnd v0.8.0-beta` is the addition of [Per-HTLC Invoice Tracking](https://github.com/lightningnetwork/lnd/pull/3390). This allows payment recipients to see additional detail and see correct balances when multiple HTLCs are paid to a single invoice. Previously, multiple payments to an invoice could cause incorrect values to be displayed in `LookupInvoice` and `ListInvoices`. Similarly, duplicate payments weren’t tracked, which made it difficult to resolve situations in which customers accidentally paid more than once. Per-HTLC Invoice Tracking also helps set the stage for Atomic Multipath Payments (AMP), which by their nature involve multiple HTLCs paying to a single invoice.
`lnd v0.8.0-beta` includes a number of “under the covers” safety improvements as well. One is “reproducible builds” which make it possible to verify whether an `lnd` binary has been generated from a specific source code repository. This makes it possible to determine whether a binary has been tampered with in a way that might introduce malicious code.
Of course, there were a few smaller safety improvements included in `lnd v0.8.0-beta`. One of those was [additional automated testing](https://github.com/lightningnetwork/lnd/pull/1583) for the `bitcoind` back-end, bringing testing for `bitcoind` to the same level of coverage as already existed for `btcd` and `neutrino`. Additionally, a [minor privacy leak](https://github.com/lightningnetwork/lnd/pull/3391) was [addressed](https://github.com/lightningnetwork/lnd/pull/3414), and [Bitcoin transaction](https://github.com/lightningnetwork/lnd/pull/3510) and [channel close transaction](https://github.com/lightningnetwork/lnd/pull/3016) broadcasting were also made more robust.
One of the biggest improvements in `lnd v0.8.0-beta` is the introduction of a much improved “Mission Control”, which is the payment routing subsystem in `lnd`. Previously, when routing payments, `lnd` could retry a similar set of routes over and over again in the case of routing failures, resulting in longer times to process payments and unnecessary failed payments in some cases. With the new, smarter Mission Control, `lnd v0.8.0-beta` will now store the past 1000 payment attempts by default (though configurable), taking note of which paths failed and which [paths succeeded](https://github.com/lightningnetwork/lnd/pull/3372). This allows Mission Control to improve future routing attempts by weighing the successful channels more strongly and decreasing attempts to use the failing channels. (Previously, only failures impacted future routing attempts.) In addition, [this data is stored](https://github.com/lightningnetwork/lnd/pull/3164) so that the data doesn’t have to be regenerated again through trial and error each time `lnd` is restarted, which happens particularly frequently on mobile devices. Other improvements such as treating [multiple parallel channels as a single logical unit](https://github.com/lightningnetwork/lnd/pull/1734), [better interpretation of failure messages](https://github.com/lightningnetwork/lnd/pull/3256) were also added to `lnd v0.8.0-beta`. In general, this entire set of improvements should make payment routing generally faster and more reliable for `lnd` users.
Another major routing-related feature added to `lnd 0.8-beta` is somewhat verbosely called “[Variable Length, Type-Length-Value Onion Payloads](https://github.com/lightningnetwork/lnd/pull/3362).” Essentially, this enables payment senders to include additional encrypted data intended for payment recipients. (The system is also flexible enough to allow for specific additional data to be sent to specific hops in a payment route.) This is a requirement for more advanced payment use cases where information needs to be transmitted securely and privately between payment participants. In particular, in multi-path payments such as AMP, additional information is transmitted that allows the receiver of multiple HTLCs to complete the combined transaction. Other potential applications include spontaneous payments, reusable invoices and rendezvous routing.
For developers and more advanced routing node operators, a new [`BuildRoute` RPC](https://github.com/lightningnetwork/lnd/pull/3440) has been added that makes it much easier to create customized payment routes. Additional routing-related controls allow nodes to have greater control of the total length of timeout they’re willing to wait for a payment using the [`--max-cltv-expiry` CLI flag](https://github.com/lightningnetwork/lnd/pull/3348), the [fees they’re willing to pay](https://github.com/lightningnetwork/lnd/pull/3401) on commitment transactions, and the [maximum size of HTLCs](https://github.com/lightningnetwork/lnd/pull/3523) they’re willing to route.
The third area of focus for `lnd v0.8.0-beta` was adding [mobile APIs and build tools](https://github.com/lightningnetwork/lnd/pull/3282). These [mobile subsystems](https://www.google.com/url?q=https://github.com/lightningnetwork/lnd/tree/master/mobile&sa=D&ust=1570734787442000&usg=AFQjCNFZP2-uTgEVynHcsNsDhkArOBb8aA) were built and tested during the process of building the Lightning Labs [desktop](https://blog.lightning.engineering/announcement/2019/04/23/mainnet-app.html) and [mobile](https://blog.lightning.engineering/announcement/2019/06/19/mobile-app.html) Apps, so include a lot of our learnings and experience with the Lightning community, our testers and users. Zap and Breez have been early pioneers with `lnd`-based mobile wallets, and we hope others in the `lnd` wallet and app development community will find these APIs and tools useful for expanding the Lightning ecosystem to many more mobile applications.
A second mobile-oriented announcement in `lnd v0.8.0-beta` is that Neutrino has steadily been improved, and this release contains several fixes and optimizations that make it [stable enough for mainnet support](https://github.com/lightningnetwork/lnd/pull/3358). Keep in mind that it is still early, and stay craeful!
#### Developers, Scalability
For developers, a few improvements were made to the RPCs in `lnd v0.8.0-beta`, in particular, the addition of the [Watchtowers subserver](https://github.com/lightningnetwork/lnd/pull/3184) to make it easier for developers to interact with [watchtowers](https://github.com/lightningnetwork/lnd/blob/master/docs/watchtower.md), and the [addition of height hints](https://github.com/lightningnetwork/lnd/pull/3405) to the Chain Notifier RPCs, which improves the scalability of that subsystem. Another addition that may be of interest to developers of `lnd`-based wallets is the addition of an [`is_graph_synced`](https://github.com/lightningnetwork/lnd/pull/3355) field in the GetInfo RPC, which can give users an indication of when they should be able to start sending payments. On the topic of graph sync, a couple small changes were made to [save bandwidth](https://github.com/lightningnetwork/lnd/pull/3366) and improve [node visibility](https://github.com/lightningnetwork/lnd/pull/2084).
#### Bug fixes
Unfortunately, even `lnd` has bugs, and in `v0.8.0-beta` we fixed several. During the channel close process, some status fields were missing, and that [has been rectified](https://github.com/lightningnetwork/lnd/pull/3456). A corner case in which setting routing fees to zero required a restart has also [been fixed](https://github.com/lightningnetwork/lnd/pull/3439). The `DescribeGraph` REST API call has been [altered so that it works correctly](https://github.com/lightningnetwork/lnd/pull/3379) with larger network graphs. There was a fix to [prevent denial-of-service attacks](https://github.com/lightningnetwork/lnd/pull/3505) with QR codes and another one to fix an [issue with missing command-line options](https://github.com/lightningnetwork/lnd/pull/3455). As always, huge thanks to our tester community for surfacing these and many other bugs and feature requests during the course of `lnd` development.
That about wraps up this summary of the latest additions in `lnd v0.8.0-beta`. We hope these improvements contribute to a safer, faster, more reliable Lightning experience. Special thanks to everyone who contributed to this release and we’re also excited to see so many contributors and Lightning community members in Berlin later this week! For more details on `lnd v0.8.0-beta`, please see the [release notes](https://github.com/lightningnetwork/lnd/releases/tag/v0.8.0-beta), chat with us on [Slack](https://lightning.engineering/slack), or message us on [Twitter](https://twitter.com/lightning)!