This release is minor release of lnd, which includes several fixes and optimizations to make lnd even better. This time around one of the points of focus has been around the reliability, robustness and speed of the Neutrino backend, which is now in a state where it can be used for building applications for the Bitcoin testnet. This will let us sort out the last quirks and performance bottlenecks before it is ready to be enabled for mainnet.

Additionally, a series of bugs have been fixed in primary wallet backend btcwallet. As a result of these prior bugs, there may have been an instance in time when your wallet missed a change addresses. The root cause of this issue has been resolved, with test coverage hardened in the affected areas. In order to ensure all funds are accounted for (and funds are safu!) lnd will perform a chain rescan from birthday once it starts up. For older nodes, nodes with many channels, and nodes with many used addresses, this may take some time. It's recommend to start your node with the LNWL=trace logging level in order to monitor the progress of the rescan.

It is highly encouraged to update to this version.

Breaking changes

• Remove NewWitnessAddress: The RPC NewWitnessAddress has been removed. Since we are only using witness addresses, addresses can be fetched using NewAddress.

A few RPCs have changed their behavior slightly, see the the RPC changes section.

Database migrations

We have made a change to the closed channels database format (see Dataloss protection improvements), and we now store the wallet's birthday block in the database to speed up rescans. If you are upgrading from an older version of lnd you should at startup see something like

2018-11-28 09:58:46.744 [INF] LTND: Active chain: Bitcoin (network=testnet)
2018-11-28 09:58:46.747 [INF] CHDB: Checking for schema update: latest_version=7, db_version=6
2018-11-28 09:58:46.747 [INF] CHDB: Performing database schema migration
2018-11-28 09:58:46.747 [INF] CHDB: Applying migration #7
2018-11-28 09:58:46.747 [INF] CHDB: Migrating to new closed channel format...
2018-11-28 09:58:46.747 [INF] CHDB: Migration to new closed channel format complete!
2018-11-28 09:58:46.762 [INF] RPCS: password RPC server listening on 127.0.0.1:10006
2018-11-28 09:58:46.762 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8086
2018-11-28 09:58:46.762 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock` to unlock an existing wallet, or `lncli changepassword` to change the password of an existing wallet and unlock it.
2018-11-28 09:59:20.459 [INF] LNWL: Applying wallet transaction manager migration #2
2018-11-28 09:59:20.459 [INF] LNWL: Dropping wallet transaction history
2018-11-28 09:59:20.459 [INF] LNWL: Applying wallet address manager migration #6
2018-11-28 09:59:20.460 [INF] LNWL: Setting the wallet's birthday block from timestamp=2018-09-16 20:15:05 +0200 CEST
2018-11-28 09:59:20.461 [INF] LNWL: Estimated birthday block from timestamp=2018-09-16 20:15:05 +0200 CEST: height=400721, hash=0000000001874116d18dca88baf9f5f41b48c69e9c01a7d4fe467df09e5de352
2018-11-28 09:59:20.461 [INF] LNWL: Applying wallet address manager migration #7
2018-11-28 09:59:21.331 [INF] LNWL: Opened wallet

Note that it will then perform a rescan from the birthday, which might take a while. By setting the debug level to debug you'll be able to track the process of this rescan.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://keybase.io/roasbeef/pgp_keys.asc | gpg --import
curl https://keybase.io/halseth/pgp_keys.asc | gpg --import

Once you have his PGP key you can verify the release (assuming manifest-v0.5.1-beta.txt and manifest-v0.5.1-beta.txt.sig are in the current directory) with:

gpg --verify manifest-v0.5.1-beta.txt.sig
gpg --verify manifest-v0.5.1-beta.txt.sig.halseth manifest-v0.5.1-beta.txt

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.5.1-beta.txt'
gpg: Signature made Wed Nov 28 13:31:43 2018 PST
gpg:                using RSA key F8037E70C12C7A263C032508CE58F7F8E20FD9A2
gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

gpg: Signature made Wed Nov 28 23:30:24 2018 CET
gpg:                using RSA key 7AB3D7F5911708842796513415BAADA29DA20D26
gpg: Good signature from "Johan T Halseth <johanth@gmail.com>" [unknown]

That will verify the signature on the main manifest page which ensures integrity and authenticity of the binaries you've downloaded locally. Next, depending on your operating system you should then re-calculate the sha256 sum of the binary, and compare that with the following hashes (which are included in the manifest file):

e0bfb53c722005d2447be2ccc0e7a5a8f0213e0733f3938264d9164d04d67ee7  lnd-darwin-386-v0.5.1-beta.tar.gz
5886c0228c97fbe5c7798f90c436a38815ac0e88112f78af025ce90b344ad888  lnd-darwin-amd64-v0.5.1-beta.tar.gz
448a6ca7015f1a225dbe162f61669c1bfd4a7a98af405877f020a5eb9ae4d41f  lnd-dragonfly-amd64-v0.5.1-beta.tar.gz
ae9ff40da44db16f51c047101b34cfc1c0903018895f041c8746c91877798a03  lnd-freebsd-386-v0.5.1-beta.tar.gz
16f8a9f357dea4e90ab025cebab57e48d93c3b9026f340d8f3de3675add3b890  lnd-freebsd-amd64-v0.5.1-beta.tar.gz
18867fed043d0a63014df65b8dda16774ede07b5d4496c5f1e6319b873c99d79  lnd-freebsd-arm-v0.5.1-beta.tar.gz
39b529597577c30b4cfa809edebed36031df5f951d0604d3f705bdfc847f8bb7  lnd-linux-386-v0.5.1-beta.tar.gz
41bff3deda46777f498a23feb7feff331638bd0a745fac43ecff99179c701675  lnd-linux-amd64-v0.5.1-beta.tar.gz
a5f3dfff3d93e420b45994b69b1eb97a183c3d3f67e143da0bbb34fb2893ba5b  lnd-linux-arm64-v0.5.1-beta.tar.gz
f714f2bd7db653f921df219fa123fd55e0090d9d4aa20f0f82aae2a2f3db31a8  lnd-linux-armv6-v0.5.1-beta.tar.gz
c8be77708fe95d5076fa6988229100598c14ae6c54e92a56d5f09f3e17732244  lnd-linux-armv7-v0.5.1-beta.tar.gz
da6798a93820889e6f0a68bf03c742510accdf2a684f0a145442e10ea8de91b9  lnd-linux-mips64-v0.5.1-beta.tar.gz
97c97b064088a809e584636733f47c2885b843cc8d802858932c6d1c1a6d5fdb  lnd-linux-mips64le-v0.5.1-beta.tar.gz
1207d49ea114ccdf6b2c10e437c3442adb2f32250444b82e58beaca1cccee443  lnd-linux-ppc64-v0.5.1-beta.tar.gz
a8324390835bb0da44296b3a7468ef3fb676b4ef8b169ca35d473bfd9beac2a0  lnd-netbsd-386-v0.5.1-beta.tar.gz
3bfd0ca1759079217dd09572ddcf0661793fc3eb1db8242d9a861b0597d4ce97  lnd-netbsd-amd64-v0.5.1-beta.tar.gz
0cdd2f32eef3849b5315c2112b90e148c4005e14fe83e5b7c8fb9235bf430447  lnd-openbsd-386-v0.5.1-beta.tar.gz
11ba3a4b5d144f2941b10353bd9b2c98ae5f4d8194c3c347d3fec998e270f8cb  lnd-openbsd-amd64-v0.5.1-beta.tar.gz
f05bcc38bd0dd9ae7f676f3587e96fdb699d0c960146fad0b56571c06bc50f65  lnd-windows-386-v0.5.1-beta.zip
c95b9374c139024bee54a254dc84d9b311c44c4f14b9613d8a7dee79f19e4b10  lnd-windows-amd64-v0.5.1-beta.zip

One can use the shasum -a 256 <file name here> tool in order to re-compute the sha256 hash of the target binary for your operating system. The produced hash should be compared with the hashes listed above and they should match exactly.

Finally, you can also verify the tag itself with the following command:

git verify-tag v0.5.1-beta

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Notable changes

Neutrino

Neutrino is a new light client for Bitcoin, that is more private and tailored for use on the Lightning Network than previous light clients. For more information, check out this blog post.

Since the previous release of lnd, the version of neutrino used has gained a lot in terms of stability and speed. We now start catching up to the necessary filter hashes the moment we have enough block headers to verify them. This let us do most of the header fetching in parallel, drastically speeding up initial sync.

A number of fixes has also been deployed to ensure neutrino correctly handles header and filter responses from multiple peers in parallel, and even peers serving invalid filters.

Height hint cache

When lnd opens channels to other nodes, it must always make sure the counterparty hasn't unilaterally closed the channel without its consent. This is done by scanning all blocks following the opening of the channel, to ensure no closing transaction has been confirmed. This is a quick check on full nodes, but since neutrino doesn't keep the entire chain around, it must request filters (and potentially blocks) from the network to perform this check.

lnd performs this scan on every restart, checking if any of its channels have been closed while offline. With the addition of height hint caches we are now able to cache the results of previous such scans, letting us start the scan from where we left off, instead of scanning the chain all the way from the block where the channel was opened. With these additions, both txid confirmations and spend detection is now cached. This saves a lot on time and bandwidth at startup, letting light client users get back into sync with the network faster.

Validating received channel updates

When sending a payment, there exists situation where the graph information the client has is not up to date with the nodes it is attempting to route through. In these cases the routing nodes will send an error back along with the updated information, such that the client can retry the payment with the correct parameters.

Previously we didn't check the signatures on this updated information, making it possible for nodes to respond with information for channels they didn't control. With an added validity check, this is no longer the case, and all graph information must be signed by the controlling parties.

forgetchannel RPC

A new RPC has been added for debug builds, that let users forcefully remove channels from their databases. This must be used with caution, as all state for the targeted channels will be lost, essentially making it impossible to recover any funds kept in these channels. This RPC is added to let advanced users get rid of leftover channels from earlier versions of lnd, where channels were not always cleaned up properly. Channels that had their funding transactions broadcast with a fee too small can also be removed with this RPC. To make sure no one uses this functionality by accident, it is only possible to use in debug builds.

Build package

A new package build has been added to lnd, greatly simplifying the process of adding build dependent changes, and improving logging during unit tests. The version string of lnd will with this change include the version tag, commit hash and number of commits since the tag. Logs from unit tests can be inspected by passing log="stdout <loglevel>" to make unit.

Smarter rate limiting

lnd will now rate limit peers that are requesting excessive amounts of data to avoid DOS attacks. Since there are still older nodes running on the network which are acting spammy during graph sync, these will quickly be rate limited. To make sure a single "bad peer" won't degrade the performance of the daemon, they are limited on a per-peer basis.

go 1.11 support

The recommended go version has been upgraded to v1.11! The project now supports go 1.10 and go 1.11.

gRPC 1.15.0

lnd uses gRPC for its RPC interface, making it easy to gain access to the functionality of lnd from a wide set of languages. The gRPC version used was due for an upgrade, and has been updated to v1.15.0, up from v1.5.2. You shouldn't be seeing any breaking changes with this upgrade.

Reject insane timelocks

We now check that forwarded payments don't impose a timelock that is too far in the future. Earlier an attacker willing to lock up his own funds could craft routes where funds got locked up for a very long time.

New sweep package

A new package sweep has been introduced, intended to take care of all kinds of sweeps within lnd, such as retrieving funds from closed channels. This is part of an ongoing effort to reduce the statefulness of funds sweeping, and be smarter about batching sweeps together in bigger transactions to save on chain fees.

rejectpush option

When opening a channel to a peer on the network, you have the option to immediately send some funds as part of the opening process (what is called push amount). For most users accepting incoming channels this is not a problem (hey, free money!), but some merchants have seen customers pushing funds to them by mistake, resulting in an annoying refund process. Now there's a new configuration option --rejectpush that makes the node reject any incoming channels that include a push amount.

Use SendToRoute with private channels

SendToRoute is an RPC that is used by advanced users to send payments along custom paths. Previously it had the restriction that the edges used in these custom paths were known to lnd. A new option pub_key in the route description given to SendToRoute lets lnd create the route without relying on the channel graph, making it possible to attempt payments even for channels unknown to lnd, such as private channels. This works since the payment is encrypted with the given public key, and now all information needed to construct the payload can be supplied over the RPC.

RPC changes

• Deprecating untyped value fields: Since RPC fields are not always typed to indicate their unit, there has been confusion especially whether satoshis or millisatoshis are used for certain RPCs. Going forward fields should indicate their type (ending with _sat or _msat), and you might see the existing, untyped fields getting deprecated.
• IncludeUnannounced flag for DescribeGraph: The DescribeGraph RPC is used to get a list of the current information found in the local graph, including all known nodes and channels. Earlier this would include information about private nodes and channels you knew about. With this recent change, the caller must explicitly set the IncludeUnannounced flag if it wishes this private information to be part of the output, to avoid this information being leaked involuntarily.
• Prevent spending unconfirmed funds by default: The SpendUnconfirmed flag must now be set for the wallet to use unconfirmed inputs when opening channels.
• Reversed QueryInvoices consistency: When querying for an offset of invoices in the reverse order, we would earlier list the first available invoice found after this offset. This was inconsistent with the non-reversed case, and has been changed.
• Number of inactive channels in GetInfo: The GetInfo RPC call now shows the number of inactive channels in addition to the number of active.

Changelog

The full list of changes since 0.5-beta can be found here:

• v0.5-beta...v0.5.1-beta

Contributors (Alphabetical Order)

AdamISZ
Alex Bosworth
Boblechinois
Carlos Garcia Ortiz
CirroStorm
Conner Fromknecht
Daniel McNally
Dave Kerr
Desuuuu
ErikEk
Francisco Calderón
Harald Nordgren
Johan T. Halseth
Joost Jager
Olaoluwa Osuntokun
Oliver Gugger
Oscar Lafarga
Patrick
Roei Erez
Valentine Wallace
Vincent Woo
Wilmer Paulino
Xavi Soler
babonet13
bluetegu
bob-333
chokoboko
maurycy
sevastos
tailnode
whythat