lnd/docs/release-notes/release-notes-0.14.0.md
2021-11-18 09:46:30 +01:00

32 KiB

Release Notes

Networking & Tor

Connectivity mode

A new flag has been added to enable a hybrid tor connectivity mode, where tor is only used for onion address connections, and clearnet for everything else. This new behavior can be added using the tor.skip-proxy-for-clearnet-targets flag.

Onion service

The Onion service created upon lnd startup is now deleted during lnd shutdown using DEL_ONION.

Tor connection

A new health check, tor connection, is added to lnd's liveness monitor upon startup. This check will ensure the liveness of the connection between the Tor daemon and lnd's tor controller. To enable it, please use the following flags,

healthcheck.torconnection.attempts=xxx
healthcheck.torconnection.timeout=xxx
healthcheck.torconnection.backoff=xxx
healthcheck.torconnection.internal=xxx

Read more about the usage of the flags in the sample-lnd.conf.

LN Peer-to-Peer Netowrk

Bitcoin Blockheaders in Ping Messages

In this release, we implement a long discussed mechanism to use the Lightning Network as a redundant block header source. By sending our latest block header with each ping message, we give peers another source (outside of the Bitcoin P2P network) they can use to spot check their chain state. Peers can also use this information to detect if they've been eclipsed from the traditional Bitcoin P2P network itself.

As is, we only send this data in Ping messages (which are periodically sent), in the future we could also move to send them as the partial payload for our pong messages, and also randomize the payload size requested as well.

The ListPeers RPC call will now also include a hex encoded version of the last ping message the peer has sent to us.

Backend Enhancements & Optimizations

Full remote database support

lnd now stores all its data in the same remote/external database such as etcd instead of only the channel state and wallet data. This makes lnd fully stateless and therefore makes switching over to a new leader instance almost instantaneous. Read the guide on leader election for more information.

Postgres database support

This release adds support for Postgres as a database backend to lnd. Postgres has several advantages over the default bbolt backend:

  • Better handling of large data sets.
  • On-the-fly database compaction (auto vacuum).
  • Database replication.
  • Inspect data while lnd is running (bbolt opens the database exclusively).
  • Usage of industry-standard tools to manage the stored data, get performance metrics, etc.

Furthermore, the SQL platform opens up possibilities to improve lnd's performance in the future. Bbolt's single-writer model is a severe performance bottleneck, whereas Postgres offers a variety of locking models. Additionally, structured tables reduce the need for custom serialization/deserialization code in lnd, saving developer time and limiting the potential for bugs.

Instructions for enabling Postgres can be found in docs/postgres.md.

In-memory path finding

Finding a path through the channel graph for sending a payment doesn't involve any database queries anymore. The channel graph is now kept fully in-memory for up a massive performance boost when calling QueryRoutes or any of the SendPayment variants. Keeping the full graph in memory naturally comes with increased RAM usage. Users running lnd on low-memory systems are advised to run with the routing.strictgraphpruning=true configuration option that more aggressively removes zombie channels from the graph, reducing the number of channels that need to be kept in memory.

There is a fallback option db.no-graph-cache=true that can be used when running a Bolt (bbolt) based database backend. Using the database for path finding is considerably slower than using the in-memory graph cache but uses less RAM. The fallback option is not available for etcd or Postgres database backends because of the way they handle long-running database transactions that are required for the path finding operations.

Protocol Extensions

Explicit Channel Negotiation

A new protocol extension has been added known as explicit channel negotiation. This allows a channel initiator to signal their desired channel type to use with the remote peer. If the remote peer supports said channel type and agrees, the previous implicit negotiation based on the shared set of feature bits is bypassed, and the proposed channel type is used. Feature bits 44/45 are used to signal this new feature.

Script Enforced Channel Leases

A new channel commitment type that builds upon the recently introduced anchors commitment format has been introduced to back channel leases resulting from Lightning Pool. This new channel commitment type features an additional spend requirement on any commitment and HTLC outputs that pay directly to the channel initiator. The channel initiator must now wait for the channel lease maturity, expressed as an absolute height of the chain, to be met before being able to sweep their funds, on top of the usual CSV delay requirement. See the linked pull request for more details.

Re-Usable Static AMP Invoices

AMP invoices are now fully re-usable, meaning it's possible for an lnd node to use a static AMP invoice multiple times. An AMP invoice can be created by adding the --amp flag to lncli addinvoice. From there repeated payments can be made to the invoice using lncli payinvoice. On the receiver side, notifications will still come in as normal, but notifying only the new "sub-invoice" paid each time.

A new field has been added to the main Invoice proto that allows callers to easily scan to see the current state of all repeated payments to a given payment_addr.

A new LookupInvoiceV2 RPC has been added to the invoicerpcserver which allows callers to look up an AMP invoice by set_id, opting to only return relevant HTLCs, or to look up an AMP invoice by its payment_addr, but omit all HTLC information. The first option is useful when a caller wants to get information specific to a repeated payment, omitting the thousands of possible other payment attempts. The second option is useful when a caller wants to obtain the base invoice information, and then use the first option to extract the custom records (or other details) of the prior payment attempts.

RPC Server

Batched channel funding

Multiple channels can now be opened in a single transaction in a safer and more straightforward way by using the BatchOpenChannel RPC or the command line version of that RPC called lncli batchopenchannel. More information can be found in the PSBT documentation.

Wallet

  • It is now possible to fund a psbt without specifying any outputs. This option is useful for CPFP bumping of unconfirmed outputs or general utxo consolidation.

  • The internal wallet can now also be created or restored by using an extended master root key (xprv) instead of an aezeed only. This allows wallet integrators to use existing seed mechanism that might already be in place. It is still not supported to use the same seed/root key on multiple lnd instances simultaneously though.

  • Publish transaction is now reachable through lncli.

  • Prior to this release, when running on simnet or regtest, lnd would skip the check on wallet synchronization during its startup. In doing so, the integration test can bypass the rule set by bitcoind, which considers the node is out of sync when the last block is older than 2 hours(more discussion). This synchronization check is put back now as we want to make the integration test more robust in catching real world situations. This also means it might take longer to start a lnd node when running in simnet or regtest, something developers need to watch out from this release.

Remote signing

It is now possible to delegate any operation that needs access to private keys to a remote signer that serves signing requests over RPC. More information can be found in the new remote signing document.

Security

  • The release signature verification script was overhauled to fix some possible attack vectors and user errors. The public keys used to verify the signatures against are no longer downloaded form Keybase but instead are kept in the lnd git repository. This allows for a more transparent way of keeping track of changes to the signing keys.

Admin macaroon permissions

The default file permissions of admin.macaroon were changed from 0600 to 0640. This makes it easier to allow other users to manage LND. This is safe on common Unix systems because they always create a new group for each user.

If you use a strange system or changed group membership of the group running LND you may want to check your system to see if it introduces additional risk for you.

Custom peer messages

Lightning nodes have a connection to each of their peers for exchanging messages. In regular operation, these messages coordinate processes such as channel opening and payment forwarding.

The lightning spec however also defines a custom range (>= 32768) for experimental and application-specific peer messages.

With this release, custom peer message exchange is added to open up a range of new possibilities. Custom peer messages allow the lightning protocol with its transport mechanisms (including tor) and public key authentication to be leveraged for application-level communication. Note that peers exchange these messages directly. There is no routing/path finding involved.

Safety

Build System

Documentation

Misc

Code Health

Code cleanup, refactor, typo fixes

Database

Performance improvements

Log system

Mission control

Bug Fixes

Documentation

The code contribution guidelines have been updated to mention the new requirements surrounding updating the release notes for each new change.

Contributors (Alphabetical Order)

  • Abubakar Nur Khalil
  • Adrian-Stefan Mares
  • Alex Bosworth
  • Alyssa Hertig
  • András Bánki-Horváth
  • Bjarne Magnussen
  • Carla Kirk-Cohen
  • Carsten Otto
  • Conner Fromknecht
  • Elle Mouton
  • ErikEk
  • Eugene Siegel
  • Hampus Sjöberg
  • Harsha Goli
  • Jesse de Wit
  • Johan T. Halseth
  • Johnny Holton
  • Joost Jager
  • Jordi Montes
  • Juan Pablo Civile
  • Kishin Kato
  • Leonhard Weese
  • Martin Habovštiak
  • Michael Rhee
  • Naveen Srinivasan
  • Olaoluwa Osuntokun
  • Oliver Gugger
  • Priyansh Rastogi
  • Roei Erez
  • Simon Males
  • Stevie Zollo
  • Torkel Rogstad
  • Wilmer Paulino
  • Yong Yu
  • Zero-1729
  • benthecarman
  • de6df1re
  • github2k20
  • mateuszmp
  • nathanael
  • offerm
  • positiveblue
  • xanoni