lnd v0.6.1-beta

This release marks a minor release in the 0.6-beta series. This release contains no major new features, and instead contains a series of bug-fixes, optimizations, and stability improvements.

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

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

gpg --verify manifest-v0.6.1-beta.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.6.1-beta.txt'
gpg: Signature made Thu May  9 16:31:08 2019 PDT
gpg:                using RSA key F8037E70C12C7A263C032508CE58F7F8E20FD9A2
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

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):

8fd4bfb26d402a4882f4c89ab700186431c178af0a9f0bf61513bbb48cd497c3  lnd-darwin-386-v0.6.1-beta.tar.gz
02330ede4e7508a37e92bcc4c0dd0ac977f51a8fd42be9f114b1e42e58ff07c9  lnd-darwin-amd64-v0.6.1-beta.tar.gz
60c7aef87789271cc1c55286068ce2e6e94ccae48d85465df0606fe96bbe01cd  lnd-dragonfly-amd64-v0.6.1-beta.tar.gz
8f328ef03e2f6fb47aab28af7a8949d3fadaac5769382d45ebbdf2fca7921593  lnd-freebsd-386-v0.6.1-beta.tar.gz
f50b91b6c0e95b2a5c0e246fb17e07eddefb77533b10c034bb5454ad4001edcd  lnd-freebsd-amd64-v0.6.1-beta.tar.gz
9e2c4b926140aacfc680e53191b1b56a18b0def422b1f8f4cc66536298721115  lnd-freebsd-arm-v0.6.1-beta.tar.gz
00a7cd0ca657bb242b0f3acb5f4e26a13fd789946fab73c252118e3f89c1cf57  lnd-linux-386-v0.6.1-beta.tar.gz
c55367edb82955dc942baf9f48f79fadde1eee0e86c1d59d2fe1993140ec1b3f  lnd-linux-amd64-v0.6.1-beta.tar.gz
d5f7280c324ebc1d322435a0eac4c42dca73ebc6a613878d9e0d33a68276da5c  lnd-linux-arm64-v0.6.1-beta.tar.gz
00ff9c61fbd272863aef677db240b04eecdaae0cfb479cf25c713b89ff81d41c  lnd-linux-armv6-v0.6.1-beta.tar.gz
5541959c7fde98d76d88cc8070ca626c681ba38c44afcb85bf417a9a677e23c2  lnd-linux-armv7-v0.6.1-beta.tar.gz
ed8aa2ef8f4e42651a16c90d5ab2d4485396b4c795bc183fd01ae63b39d4201e  lnd-linux-mips64-v0.6.1-beta.tar.gz
a97dfc432747f4dcd6deb8f263b18453c68b4882b1cc1ff84d90f25ba2ed5151  lnd-linux-mips64le-v0.6.1-beta.tar.gz
95ff869a1bbcba20b5c6387f09175eaf3a16f2026e5113eff9abb7b595039423  lnd-linux-ppc64-v0.6.1-beta.tar.gz
5efb454850f41f69a397d4a9cd4778f6a251ce21cf796960b60d6799ff128bf1  lnd-netbsd-386-v0.6.1-beta.tar.gz
6059ab2d6d03604d48c69eeaf1f59f2131b1ce76f714629a6e1c2063f4da4788  lnd-netbsd-amd64-v0.6.1-beta.tar.gz
5db4391a3d5646c3adcdaa1f57fbd9a8b9cfb585e38cccc37729bd5fe2bca8e6  lnd-openbsd-386-v0.6.1-beta.tar.gz
c5b84fe5982ae4b7745d0f083d123d304f97c5da4e6fe515f84b3272495fb1a2  lnd-openbsd-amd64-v0.6.1-beta.tar.gz
68fcede095d6e4f038ba49c46f24a07ff2d07ea11eab95d2d02d5c1467d4d2fc  lnd-source-v0.6.1-beta.tar.gz
e2cb484fda567eb03a534f36613771b1bc10c7220b255b3972784f38abdc2342  lnd-windows-386-v0.6.1-beta.zip
c370735f280ab2b5f6421dafccbdc0e09ff5cfe5f3a65f87155d5cf1e20b1249  lnd-windows-amd64-v0.6.1-beta.zip
afb75c146f03bc4d2af77c49ac4ced88f945a5d3cb9ba32181bc9145149e6af6  vendor.tar.gz

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.6.1-beta

Building the Contained Release

With this new version of lnd, we've modified our release process to ensure the bundled release is now fully self contained. As a result, with only the attached payload with this release, users will be able to rebuild the target release themselves without having to fetch any of the dependencies. Note that at this stage, binaries aren't yet fully reproducible (even with go modules). This is due to the fact that by default, Go will include the full directory path where the binary was built in the binary itself. As a result, unless your file system exactly mirrors the machine used to build the binary, you'll get a different binary, as it includes artifacts from your local file system. This will be fixed in go1.13, and before then we may modify our release system to do this automatically.

In order to re-build from scratch, assuming that vendor.tar.gz and lnd-source-v0.6-beta.tar.gz are in the current directory:

tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.6.1-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.6.1-beta" ./cmd/lnd
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.6.1-beta" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

LNDBUILDSYS="linux-arm64 darwin-amd64" ./release.sh

The release.sh script will now also properly include the commit hash once again, as a regression caused by a change to the internal build system has been fixed.

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

Release Notes

Tor

A bug has been fixed in the minimum version verification for the Tor daemon that lnd enforces. Before this fix, lnd would at times fail to connect to a Tor daemon with a version beyond the minimum version we require.

Protocol and Cross Implementation Compatibility Improvements

lnd will now properly handle the conversion from an UpdateFailMalformedHTLC error to a regular UpdateFailHTLC error. Before this fix, lnd would incorrectly send an error that wasn't able to be decrypted by the sender of an the original HTLC.

On-Chain Commitment/HTLC Handling

A series of parameters related to when lnd will go to chain for an HTLC, and also when it will reject an incoming/outgoing HTLC for being "too close for comfort" have been adjusted. As a result, it's no longer possible for lnd to accept an HTLC then immediately go to chain for it. Additionally, it's now possible for lnd to forward an HTLC as the last hop to a destination with a very low final CLTV delta.

lnd will now detect a local force close (self initiated) based on the outputs rather then the old txid based comparison. This patches an edge case related to SCB restoration where if a user broadcasted a force close then restored their SCB, lnd would miss this local force close transaction and attempt to redeem using an incorrect path. This bug has never been observed in the wild, but nevertheless warranted patching.

Gossip and P2P Handling

Non Write Pool Blocking Writes

Flushing a message to the socket is no longer blocks the write pool. One result of this change is that we are now we are able to gracefully handle timeout errors and resume partially sent messages. As of #2819, if a message is partially written to the wire due to a timeout error, we will try to write the full message again. In turn, this will produce an authentication error on the remote side (after it is able to read the number of bytes specified in the header) since the middle of the latter ciphertext will not pass as the MAC check.

We resolve this by splitting the Write call into two subroutines, WriteMessage and Flush. WriteMessage encrypts the plaintext and buffers the ciphertext on the underlying connection. A subsequent call to Flush will then attempt to write the bytes out on the wire. If a timeout error is encountered during flush, we can safely resume the byte stream by calling Flush again. In addition to being able to resume partial writes, this also has a yuuuge benefit in not blocking the write pool with network operations. This fully decouples the number of write pool workers from the number of peers, since the blocking operations now take place in each peer.

Synchronous Gossip Response Writes

All replies to gossip query messages are now fully synchronous. This means that if a peer requests a set of channels, then we won't send the next message until after the current message has been flushed to the socket. Node operators should find that start up is now much snappier, and the post start up memory burst to also be much lower.

SyncManager Simplification and Improvements

We've made some improvements to the recently introduced SyncManager. These improvements include:

• Active syncers will no longer attempt to synchronize our graph with remote peers. Instead, we'll now rely on synchronizing our graph with remote peers through the routine historical syncs performed by the SyncManager. Since active syncers will no longer attempt this synchronization, the SyncManager's round-robin is no longer needed.
• Handling initial h...

lnd v0.6-beta

This release marks a new major release of lnd that includes several important bug fixes, numerous performance optimizations, static channel backups (SCB), reduced bandwidth usage for larger nodes, an overhaul of the internals of the autopilot system, and a new batch sweeping sub-system. Due to the nature of some of the bug fixes which were made during the implementation of the new SCB feature, users are highly encouraged to upgrade to this new version.

Database migrations

This version includes a single migration to modify the message store format, used to send messages to remote peers reliably when attempting to construct channel proofs. The migration should appear as below:

2019-04-03 22:35:44.596 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta, build=production, logging=default
2019-04-03 22:35:44.596 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-04-03 22:35:44.597 [INF] CHDB: Checking for schema update: latest_version=8, db_version=7
2019-04-03 22:35:44.597 [INF] CHDB: Performing database schema migration
2019-04-03 22:35:44.597 [INF] CHDB: Applying migration #8
2019-04-03 22:35:44.597 [INF] CHDB: Migrating to the gossip message store new key format
2019-04-03 22:35:44.597 [INF] CHDB: Migration to the gossip message store new key format complete!

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

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

gpg --verify manifest-v0.6-beta.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.6-beta.txt'
gpg: Signature made Tue Apr 16 14:35:13 2019 PDT
gpg:                using RSA key F8037E70C12C7A263C032508CE58F7F8E20FD9A2
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

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):

e9f3ff0f551f3ce4ad113ad10f8009a3aaca82fb6cd0244a994c299602b29334  lnd-darwin-386-v0.6-beta.tar.gz
76816b2d0d0e3f4c0e7d41c0ecb1457afe2ba95b8f37f4aa1adebbd9bc19aa4b  lnd-darwin-amd64-v0.6-beta.tar.gz
f7650749dc50c3f8c1957680333d95562b159ed13fea26737dc29bff76212925  lnd-dragonfly-amd64-v0.6-beta.tar.gz
7b77ecbfcffb3e2151ff54c27133aebe0d9b6324c80594bce4df265b5f990f61  lnd-freebsd-386-v0.6-beta.tar.gz
d48ce7ed7cc71e988af65e4175e949a5e52f2b8109f5239ae595edc3b8442f05  lnd-freebsd-amd64-v0.6-beta.tar.gz
c783ce9987577d2b7a5e95b6a16767158ef98f48d0eeedf58f4c3a1ce7500e6d  lnd-freebsd-arm-v0.6-beta.tar.gz
cde995167b428696cd6e78733fd934ebda9e03c0b63938af4654c42bd2d86e88  lnd-linux-386-v0.6-beta.tar.gz
ef37b3658fd864dfb3af6af29404d92337229378c24bfb78aa2010ede4cd06af  lnd-linux-amd64-v0.6-beta.tar.gz
2f31b13a4da6217ed7e27a44e1705103d7ed846aa2f599b7e5de0e6033a66c19  lnd-linux-arm64-v0.6-beta.tar.gz
ae8571de0e033a05279469348102982fcfbd3f88c83d549a3d43165ab8ab5aa0  lnd-linux-armv6-v0.6-beta.tar.gz
effea372c207293fd42b0cc27800da3a70c22f8c9a0e7b5eb8dbe56b5b98e1a3  lnd-linux-armv7-v0.6-beta.tar.gz
61038e6cd67562ba3d832de38917d6d37b0cb74fe5e32d4d41fb6d9193f8109d  lnd-linux-mips64-v0.6-beta.tar.gz
28e5be6510fbae4f893253b34db0fcc92d720016f46abe00684a00d2d11a1be3  lnd-linux-mips64le-v0.6-beta.tar.gz
5c13f83344d2634763cf4e178a2d2ca69031a985030713d585d3b37f7a261c06  lnd-linux-ppc64-v0.6-beta.tar.gz
07e91fc56cb0cfcfe52dcaa2bdec008c401b04fe466e970449bcdb4ebb6bb077  lnd-netbsd-386-v0.6-beta.tar.gz
465f4649bdb1393543de52b0dc60aa6121fad0bcf5ad8e7ff62a72c2484dd264  lnd-netbsd-amd64-v0.6-beta.tar.gz
f75b70cf657bffef6cbf2147f69e4296fb98adb48bd18e26950aedb7802748e9  lnd-openbsd-386-v0.6-beta.tar.gz
e5ce0e16a815d5ad98a60c9f7a148efcdb083c0af73965962156f2e3fc03e0df  lnd-openbsd-amd64-v0.6-beta.tar.gz
2c46e9e1f519fe7b0177f30c77611591023442df63c0a1e186154baf7dd9a284  lnd-source-v0.6-beta.tar.gz
77069e9971cd3240891698c02d821ae28254f765c77b5f943b6b88b4943434e7  lnd-windows-386-v0.6-beta.zip
b84de3702074f7e6ecab5f60a1489fb4ee9cd83bcf7c7e9a44604c600ff1d37e  lnd-windows-amd64-v0.6-beta.zip
31205f95fcf7bab7eeff043807ef0485ca14f4506e2e3864db81411ef637aebc  vendor.tar.gz

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.6-beta

Building the Contained Release

With this new version of lnd, we've modified our release process to ensure the bundled release is now fully self contained. As a result, with only the attached payload with this release, users will be able to rebuild the target release themselves without having to fetch any of the dependencies. Note that at this stage, binaries aren't yet fully reproducible (even with go modules). This is due to the fact that by default, Go will include the full directory path where the binary was built in the binary itself. As a result, unless your file system exactly mirrors the machine used to build the binary, you'll get a different binary, as it includes artifacts from your local file system. This will be fixed in go1.13, and before then we may modify our release system to do this automatically.

In order to re-build from scratch, assuming that vendor.tar.gz and lnd-source-v0.6-beta.tar.gz are in the current directory:

tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.6-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.6-beta"
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.6-beta" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

LNDBUILDSYS="linux-arm64 darwin-amd64" ./release.sh

The release.sh script will now also properly include the commit hash once again, as a regression caused by a change to the internal build system has been fixed.

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

Release Notes

Protocol and Cross-Implementation Compatibility Fixes

We’ll now properly validate our own announcement signatures for NodeAnnouncements before writing them to disk and propagating them to other peers.

A bug has been fixed causing us to send an FinalFailExpiryTooSoon error rather than a FinalFailIncorrectCltvExpiry when the last HTLC of a route has an expiration height that is deemed too soon by the final destination of the HTLC.

Aliases received on the wire are now properly validated. Additionally, we’ll no longer disconnect peers that send us invalid aliases.

A bug has been fixed that would at times cause commitments to desynchronize in the face of multiple concurrent updates that included an UpdateFee message. The fix generalizes the existing commitment state machine logic to treat an UpdateFee message as we would any other Update* messages.

We’ll now reject funding requests that require an unreasonable confirmation depth before the channel can be used.

We’ll now space out our broadcast batches more in order to save bandwidth and consolidate more updates behind a single batch.

We’ll now require all peers we connect to, to have the DLP (Data Loss Protection) bit set. This is required for the new SCB (Static Channel Backups) to function properly.

For private channels, we’ll now always resend the latest ChannelUpdate to the remote peer on reconnecting. This update is required to properly make invoices with hop hints which are required for receiving over a non-advertised channel.

Reject and Channel Caches

A number of internal caches have been added to reduce memory idle memory usage with a large number of peers, and also reduce idle CPU usage due to stale channel updates.

In this release, lnd now maintains a small reject cache for detecting stale ChannelAnnouncment and ChannelUpdate messages from its peers. Prior versions of lnd would perform a database lookup for each incoming messages, which produced a huge amount of contention under load and as the channel graph exploded.

The reject cache maintains just 25 bytes per edge, and easily holds today's graph in memory. Users on low power devices or with a large number of peers will benefit immensely from lnd's improved ability to filter gossip traffic for the latest information and clear large...

lnd v0.6-beta-rc4

This release marks a new major release of lnd that includes several important bug fixes, numerous performance optimizations, static channel backups (SCB), reduced bandwidth usage for larger nodes, an overhaul of the internals of the autopilot system, and a new batch sweeping sub-system. Due to the nature of some of the bug fixes which were made during the implementation of the new SCB feature, users are highly encouraged to upgrade to this new version.

Database migrations

This version includes a single migration to modify the message store format, used to send messages to remote peers reliably when attempting to construct channel proofs. The migration should appear as below:

2019-04-03 22:35:44.596 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc4, build=production, logging=default
2019-04-03 22:35:44.596 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-04-03 22:35:44.597 [INF] CHDB: Checking for schema update: latest_version=8, db_version=7
2019-04-03 22:35:44.597 [INF] CHDB: Performing database schema migration
2019-04-03 22:35:44.597 [INF] CHDB: Applying migration #8
2019-04-03 22:35:44.597 [INF] CHDB: Migrating to the gossip message store new key format
2019-04-03 22:35:44.597 [INF] CHDB: Migration to the gossip message store new key format complete!

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

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

gpg --verify manifest-v0.6-beta-rc4.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.6-beta-rc4.txt'
gpg: Signature made Thu Apr 11 16:36:48 2019 PDT
gpg:                using RSA key F8037E70C12C7A263C032508CE58F7F8E20FD9A2
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

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):

b5fd7f1f0fb2d15ea7733093891fec0b0da2a8559b3f8af35d9b90e7e9f1f88d  lnd-darwin-386-v0.6-beta-rc4.tar.gz
21bf54da68ff0274c9533c42960ede68bfbdd1c0d6731f98a4840581c373ef82  lnd-darwin-amd64-v0.6-beta-rc4.tar.gz
a91aba806048be5cb0edc832592628770c4a9551b1b0fa5929379e0e84697f13  lnd-dragonfly-amd64-v0.6-beta-rc4.tar.gz
b7e6061a80280fe410b0b89936c4aae1bb710ad5d2c12e753458d15e03315650  lnd-freebsd-386-v0.6-beta-rc4.tar.gz
0257b8a370966e8b4a811025bf8f7ef4db0bd41b3b5b261b7db32c8374d50bcd  lnd-freebsd-amd64-v0.6-beta-rc4.tar.gz
7db9bb741d6ff2f7eeb8971157145a4fcee448fb32410eff62bbc7a74eb5ab27  lnd-freebsd-arm-v0.6-beta-rc4.tar.gz
3af9247ac71da98db8690dcf1f2b7c3e041a05fe557c00dd25116e114851224b  lnd-linux-386-v0.6-beta-rc4.tar.gz
e03680698dc980885f2aa794953b8abffb0b672e2baf042d6deed62ecd8bfd26  lnd-linux-amd64-v0.6-beta-rc4.tar.gz
43c86a8fd50dc54d942bc85883202396da063780c249769f7b97b2159e8d5630  lnd-linux-arm64-v0.6-beta-rc4.tar.gz
92b61e47c6fa741b1f3ff7507e1fe8c540d87ece272b5b3b1d7104228ce15c7a  lnd-linux-armv6-v0.6-beta-rc4.tar.gz
3ed4b5e54afb6bf083a9693058dbf7d490e15837da5e5dc49ba06bfb942a1312  lnd-linux-armv7-v0.6-beta-rc4.tar.gz
41c96d503eb7f166b95963a3d0c25e39ad43e4719ce1b61f07481b96e4adf6c5  lnd-linux-mips64-v0.6-beta-rc4.tar.gz
fe3a4fd2ad36c1cb5aa2bbc6dcaca67cbe22fa3bc40d2494c55a6713dd1ccc31  lnd-linux-mips64le-v0.6-beta-rc4.tar.gz
f910d790956dd6db56b0fb4f08e88eff3453cc4eccac974f9cbb5dccdde794ec  lnd-linux-ppc64-v0.6-beta-rc4.tar.gz
b9591ee4d92811d3e5a6a1c7162788acb53000087db535ec53b945c2204cc42c  lnd-netbsd-386-v0.6-beta-rc4.tar.gz
4f66044356d144face2687c80a09b63860b949f874a1e80d6abdab1106bdbbf3  lnd-netbsd-amd64-v0.6-beta-rc4.tar.gz
2b9055ddd3686ebe3eb266a95fa6231319b9c29cf130b8ab8513c3af48e5158f  lnd-openbsd-386-v0.6-beta-rc4.tar.gz
8f900a1fab45aaabbee9ff50ce2140ae8f36f14e84ad4a2d56d5c50ebfcaba84  lnd-openbsd-amd64-v0.6-beta-rc4.tar.gz
0befbe91617e837287f391f08f374a8ac0b88b0770c5b1a79eaa4987fe334fe0  lnd-source-v0.6-beta-rc4.tar.gz
4ec02a37c7fd923f7f0114f889a1b6d042617e9dc870d1f42a31ef0caff1ae84  lnd-windows-386-v0.6-beta-rc4.zip
22545a7c5db140e4e42ea658befd38ea8d422d909e7811196e18308870ec5aae  lnd-windows-amd64-v0.6-beta-rc4.zip
9880b8643c3fc1cfce755cec8329e6a3372664e91bce5ae2cf2dfe7aba325d2d  vendor.tar.gz

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.6-beta-rc4

Building the Contained Release

With this new version of lnd, we've modified our release process to ensure the bundled release is now fully self contained. As a result, with only the attached payload with this release, users will be able to rebuild the target release themselves without having to fetch any of the dependencies. Note that at this stage, binaries aren't yet fully reproducible (even with go modules). This is due to the fact that by default, Go will include the full directory path where the binary was built in the binary itself. As a result, unless your file system exactly mirrors the machine used to build the binary, you'll get a different binary, as it includes artifacts from your local file system. This will be fixed in go1.13, and before then we may modify our release system to do this automatically.

In order to re-build from scratch, assuming that vendor.tar.gz and lnd-source-v0.6-beta-rc4.tar.gz are in the current directory:

tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.6-beta-rc4.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.6-beta"
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.6-beta" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

LNDBUILDSYS="linux-arm64 darwin-amd64" ./release.sh

The release.sh script will now also properly include the commit hash once again, as a regression caused by a change to the internal build system has been fixed.

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

Release Notes

Protocol and Cross-Implementation Compatibility Fixes

We’ll now properly validate our own announcement signatures for NodeAnnouncements before writing them to disk and propagating them to other peers.

A bug has been fixed causing us to send an FinalFailExpiryTooSoon error rather than a FinalFailIncorrectCltvExpiry when the last HTLC of a route has an expiration height that is deemed too soon by the final destination of the HTLC.

Aliases received on the wire are now properly validated. Additionally, we’ll no longer disconnect peers that send us invalid aliases.

A bug has been fixed that would at times cause commitments to desynchronize in the face of multiple concurrent updates that included an UpdateFee message. The fix generalizes the existing commitment state machine logic to treat an UpdateFee message as we would any other Update* messages.

We’ll now reject funding requests that require an unreasonable confirmation depth before the channel can be used.

We’ll now space out our broadcast batches more in order to save bandwidth and consolidate more updates behind a single batch.

We’ll now require all peers we connect to, to have the DLP (Data Loss Protection) bit set. This is required for the new SCB (Static Channel Backups) to function properly.

For private channels, we’ll now always resend the latest ChannelUpdate to the remote peer on reconnecting. This update is required to properly make invoices with hop hints which are required for receiving over a non-advertised channel.

Reject and Channel Caches

A number of internal caches have been added to reduce memory idle memory usage with a large number of peers, and also reduce idle CPU usage due to stale channel updates.

In this release, lnd now maintains a small reject cache for detecting stale ChannelAnnouncment and ChannelUpdate messages from its peers. Prior versions of lnd would perform a database lookup for each incoming messages, which produced a huge amount of contention under load and as the channel graph exploded.

The reject cache maintains just 17 bytes per edge, and easily holds today's graph in memory. Users on low power devices or with a large number of peers will...

lnd v0.6-beta-rc3

lnd v0.6-beta-rc3

lnd v0.6-beta-rc2

lnd v0.6-beta-rc2

lnd v0.5.2-beta

This release is minor release of lnd, which includes several fixes which increase the stability of lnd, and also further increases cross implementation compatibility. There are no new database migrations, or functional RPC changes in this new version. As a result, users should expect a smooth upgrade path with no manual intervention required.

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

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

gpg --verify manifest-v0.5.2-beta.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.5.2-beta.txt'
gpg: Signature made Thu Feb  7 13:29:16 2019 PST
gpg:                using RSA key F8037E70C12C7A263C032508CE58F7F8E20FD9A2
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

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):

8c1d4c50847c665ac277bc8a659b8320f8a053d074a05e99c59f52ac87033968  lnd-darwin-386-v0.5.2-beta.tar.gz
478833d7d4efbbfe5c04f6ce7f5d69f45a163fcca0d4b83a1cba96556e76b916  lnd-darwin-amd64-v0.5.2-beta.tar.gz
8c351581f7887e5eeb9b2fc905e2057e5d1b03d5e58c29acbaeb19fb320cc157  lnd-dragonfly-amd64-v0.5.2-beta.tar.gz
29bc87951a65d8541b355cba3600db5439d70720addfb8c194a5e035fd20ff47  lnd-freebsd-386-v0.5.2-beta.tar.gz
5dfb7eb58039389f14d0c76a5a54f7d890c80f97ad1be3cb7e39a032b19634b5  lnd-freebsd-amd64-v0.5.2-beta.tar.gz
6422cdee33b42b7efcad84fff4c3d6dddd3e6f015057b7b131f6ce262cc2bf61  lnd-freebsd-arm-v0.5.2-beta.tar.gz
ae2858e8ae7b2cfd9b0901032634056f9839bc26d01edc32e26524d2ba386084  lnd-linux-386-v0.5.2-beta.tar.gz
d876ffe5f18431cb0ec97c75e3d8b34a8d2c84e36a0114636a92dabe71340a99  lnd-linux-amd64-v0.5.2-beta.tar.gz
e178ba9aa7b207b5381519c34fd0b24cc74eebb0e1498536cf267988c6946858  lnd-linux-arm64-v0.5.2-beta.tar.gz
f03401fb24ce7a5d4dc498a6f3c88a766c186ac88d7f52791ecb95b5e983ef5c  lnd-linux-armv6-v0.5.2-beta.tar.gz
9adf9f3d0b8a62942f68d75ffe043f9255319209f751dee4eac82375ec0a86cd  lnd-linux-armv7-v0.5.2-beta.tar.gz
e8ef8bd34384b8f9c52198a53034c30f162cccb8b31262b822424d640ad5dfaf  lnd-linux-mips64-v0.5.2-beta.tar.gz
33037ed61c7f0c1939b1233d579fb39aa9261086f75dd24c7172ea3dba1aa63f  lnd-linux-mips64le-v0.5.2-beta.tar.gz
671bf900995eaa9349e869383397580c9f4d6cbe4d5fbb32673c7b217b4fe10f  lnd-linux-ppc64-v0.5.2-beta.tar.gz
3d3b4d117594becd19f89c1ed82a6167b53a8b22a3351e85b5d21045ade821e8  lnd-netbsd-386-v0.5.2-beta.tar.gz
b090505e313a9998d307c06dc340908145167f262746accca6f330f1d74bbfad  lnd-netbsd-amd64-v0.5.2-beta.tar.gz
d720671b9fc253c4e857bb53875daa15a367b21d20e2d9d2e149714315cfb15a  lnd-openbsd-386-v0.5.2-beta.tar.gz
af0db952379a67e40f988eb94261f59fb0173f63de1806eb38c529751dd6c674  lnd-openbsd-amd64-v0.5.2-beta.tar.gz
f3b601a66fe5a277f8e7600637f15712146971be11adf7074cc01a0edd869be7  lnd-source-v0.5.2-beta.tar.gz
64ce298461dae68133823b3b43cfa7cb05e821e7688f29df14fbce02e64e14a9  lnd-windows-386-v0.5.2-beta.zip
9ac0667a877e3884627c019390cc593b5a783777314b2e30121aac76d1c71993  lnd-windows-amd64-v0.5.2-beta.zip
70607224b051c8919090f108669c35f5582c080cc0341ee1fe953b10b82368ca  vendor.tar.gz

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.2-beta

Building the Contained Release

With this new version of lnd, we've modified our release process to ensure the bundled release is now fully self contained. As a result, with only the attached payload with this release, users will be able to rebuild the target release themselves without having to fetch any of the dependancies. Note that at this stage, binaries aren't yet fully reproducible (even with
go modules). This is due to the fact that by default, Go will include the full directory path where the binary was built in the binary itself. As a result, unless your file system exactly mirrors the machine used to build the binary, you'll get a different binary, as it includes artifacts from your local file system. This will be fixed in go1.13, and before then we may modify our release system to do this automatically.

In order to re-build from scratch, assuming that vendor.tar.gz and lnd-source-v0.5.2-beta.tar.gz are in the current directory:

tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.5.2-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.5.2-beta"
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.5.2-beta" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

LNDBUILDSYS="linux-arm64 darwin-amd64" ./release.sh

The release.sh script will now also properly include the commit hash once again, as a regression caused by a change to the internal build system has been fixed.

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

Notable changes

Expansion of lncli block size

In this release, we increase the gRPC block size from 4MB to 50MB. Recently, the output of lncli describegraph has hit the block size cap due to the expansion of the mainnet graph. Without this attempts to fetch the graph return an error of:

[lncli] rpc error: code = ResourceExhausted desc = grpc: received message larger than max (4246753 vs. 4194304)

With this commit, we give ourselves some breathing room. It's important to note that the max message size limit is a client side setting. As a result, any developers driving lnd with gRPC will also need to raise their block size limit as well if they wish to fetch the graph over gRPC.

Switch to Go Modules for Dependency Management

With this release, lnd now uses go modules rather than glide to handle our package dependency management. End users and developers should see no functional change, as the Makefile is still the primary interaction point when building and testing lnd. Switching to go modules also preps us for the fully reproducible binary builds for Go which are slated to land in go1.13.

Wallet Bug Fixes

The wallet will no longer rescan from the seed birthday if a wallet has no UTXOs once it has already been created.

Config and Wire Protocol Validation Fixes

A node's color is now properly validated when passed in as a config or command line parameter. This fix ensures that we're able to properly parse a hex color before attempting to commit it to the database. With this change, if an invalid color is passed, then lnd will refuse to start.

We'll now validate our own node announcement as a sanity check to ensure generated announcements elsewhere in lnd are fully protocol compliant.

We'll now properly avoid creating empty buckets within bolt which have been the source of prior inadvertent bugs.

We'll now ensure that we don't accept any node announcements with an invalid alias.

A bug has been fixed wherein we'd encode an invalid (too long) length for the enclosed ChannelUpdate within an onion error. This didn't affect lnd nodes as we didn't rely on the encoded length when decoding the error payload. However, other implementations did, which rendered them unable to decode a sub-set of our onion error messages.

lnd will now reject (by default) requests for funding confirmations that we deem are too large.

A bug related to the FeeUpdate message has been fixed which could at times cause two channels to de-synchronize.

lnd, will no longer send the IncorrectHtlcAmount error. Instead, it will now use the new UnknownPaymentHash error that includes the amount of the HTLC.

Network Level Channel Advertisements

All channels created by lnd will now properly have the new max_htlc field set. This is a prep for our upcoming AMP implementation. Payment splitting heuristics can use this value as a guide when determining payment chunk size, an...

lnd v0.5.1-beta

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 <[email protected]>" [ultimate]

gpg: Signature made Wed Nov 28 23:30:24 2018 CET
gpg:                using RSA key 7AB3D7F5911708842796513415BAADA29DA20D26
gpg: Good signature from "Johan T Halseth <[email protected]>" [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...

lnd v0.5.1-beta-rc1

lnd v0.5.1-beta-rc1

lnd v0.5-beta

This release marks the 5th major release release of lnd: v0.5-beta! This release marks a massive step in the robustness and reliability of lnd as a routing node daemon for the Lightning Network. Additionally, a number of optimizations have been implemented which will reduce the memory and CPU footprint of lnd making it more amendable to run on smaller devices like Raspberry Pis and also eventually mobile phones! A number of bug fixes related to reliable HTLC forwarding, persistence recovery, and path finding have also landed in this release. As a result users should generally find path finding to be a smoother experience, and should find that lnd is able to recover from a number of partial and complete failures in routine protocol exchanges.

The 0.5-beta release doesn't include any strictly breaking changes. So a result, users should find the upgrade process to be smooth. If one is upgrading from 0.4.2, the initial starting logs should look something like:

2018-09-16 21:55:16.911 [INF] LTND: Version 0.5.0-beta commit=14bc024030d8603fd21b9d18e27a7bb061815d26
2018-09-16 21:55:16.911 [INF] LTND: Active chain: Bitcoin (network=testnet)
2018-09-16 21:55:16.911 [INF] CHDB: Checking for schema update: latest_version=6, db_version=0
2018-09-16 21:55:16.911 [INF] CHDB: Performing database schema migration
2018-09-16 21:55:16.911 [INF] CHDB: Applying migration #1
2018-09-16 21:55:16.911 [INF] CHDB: Populating new node update index bucket
2018-09-16 21:55:16.913 [INF] CHDB: Populating new edge update index bucket
2018-09-16 21:55:16.981 [INF] CHDB: Migration to node and edge update indexes complete!
2018-09-16 21:55:16.981 [INF] CHDB: Applying migration #2
2018-09-16 21:55:16.981 [INF] CHDB: Migrating invoice database to new time series format
2018-09-16 21:55:16.981 [INF] CHDB: Migration to invoice time series index complete!
2018-09-16 21:55:16.981 [INF] CHDB: Applying migration #3
2018-09-16 21:55:16.981 [INF] CHDB: Applying migration #4
2018-09-16 21:55:17.028 [INF] CHDB: Migration of edge policies complete!
2018-09-16 21:55:17.028 [INF] CHDB: Applying migration #5
2018-09-16 21:55:17.028 [INF] CHDB: Migrating database to support payment statuses
2018-09-16 21:55:17.028 [INF] CHDB: Marking all known circuits with status InFlight
2018-09-16 21:55:17.028 [INF] CHDB: Marking all existing payments with status Completed
2018-09-16 21:55:17.028 [INF] CHDB: Applying migration #6
2018-09-16 21:55:17.029 [INF] CHDB: Migrating database to properly prune edge update index
2018-09-16 21:55:17.218 [INF] CHDB: Migration to properly prune edge update index complete!

Breaking Changes

• One lncli related change that users running on simnet or testnet will notice is that the default location for macaroons has now changed. As a result, lnd will generate a new set of macaroons after it has initially been upgraded. Further details will be found below, but lnd will now generate a distinct set of macaroons for simnet, testnet, and mainnet. As a result, you may need to supply additional arguments for lncli to have it work as normal on testnet like so:

  lncli --network=testnet getinfo
  

  or

  lncli --chain=litecoin --network=testnet getinfo
  

  In order to cut down on the typing one needs to go through, we recommend creating an alias like so:

  alias tlncli=lncli --network=testnet
  

  NOTE: In this release, the --noencryptwallet command line and config argument to lnd has been phased out. It has instead been replaced with an argument identical in functionality, but distinct in naming: --noseedbackup. The rationale for this change is to remove the foot gun that was the prior config value, as many users would unknowingly create mainnet nodes using the argument. This is dangerous, as if done, the user wouldn't receive a recovery mnemonic to recover their on-chain funds in the case of disaster. We've changed the name of the argument to better reflect the underlying semantics.

• Users running a bitcoind backend will need to modify their existing ZMQ-related settings. Previously, lnd listened on one shared port for both blocks and transactions. 0.5 requires two distinct ports to be set, such that they are isolated. Users should remove the old bitcoind.zmqpath entry in lnd.conf, and, for example, replace it with:

   bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332
   bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333
  

  Also ensure that bitcoind is exposing distinct ZMQ ports in bitcoin.conf:

  zmqpubrawblock=tcp://127.0.0.1:28332
  zmqpubrawtx=tcp://127.0.0.1:28333
  

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 roasbeef's key if you haven't done so already:

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

The keybase page of roasbeef includes several attestations across distinct platforms in order to provide a degree of confidence that this release was really signed by "roasbeef".

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

gpg --verify manifest-v0.5-beta.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.5-beta.txt'
gpg: Signature made Fri Sep 14 13:26:49 2018 PDT
gpg:                using RSA key F8037E70C12C7A263C032508CE58F7F8E20FD9A2
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

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):

4f88ab4f19a41193e2e246a13981cec3c20f5b3bb7422af60955acf1a077e1cd  lnd-darwin-386-v0.5-beta.tar.gz
079c5398b952f8a479b3b0cad3bac2d4bcd52f7d5140688da2255728a607cf76  lnd-darwin-amd64-v0.5-beta.tar.gz
03942a1b09287653767c57278180806ad26f943e80121c2ce2fda9856438ffdf  lnd-dragonfly-amd64-v0.5-beta.tar.gz
95cc950191a1cddf03010052a3fd5b92971bbbfe53f84a17290863bb09974705  lnd-freebsd-386-v0.5-beta.tar.gz
9b7b92077a301cacaf5fe9a1f19473c9cc44adffaee401b1028c6d313882c574  lnd-freebsd-amd64-v0.5-beta.tar.gz
0834b4cd949cea3a3602c5c532e1f4b31ceba6ea6a54a47b941170709991086f  lnd-freebsd-arm-v0.5-beta.tar.gz
7fddc4a8cc039535a9450c24dc253f34a2d7620d306aaa894d6313ec510bf5b7  lnd-linux-386-v0.5-beta.tar.gz
d42ebcc3626016417c9473285190db90e4d7a634c69142fa16f0b182befe7edc  lnd-linux-amd64-v0.5-beta.tar.gz
b634e8877d18079d4a8dbdb6e8126806a1fd51a1752c00b934379b0f0fd93577  lnd-linux-arm64-v0.5-beta.tar.gz
3ac1113ae94c99609abd0c4da78f472689277551a9bd8e1a4e33d8b5051c8675  lnd-linux-armv6-v0.5-beta.tar.gz
f3d578e90061541935e0de888a40377d5131bb5008317ff8af11e245fe2c8510  lnd-linux-armv7-v0.5-beta.tar.gz
b842bdb31410a1de45e8edbeaade49987e7277592b846e8ef2f26421b71d9b9f  lnd-linux-mips64-v0.5-beta.tar.gz
b00489e3dc31359578011559acc88e851d53a6a4b9d7a49d4da5d4f614f25b55  lnd-linux-mips64le-v0.5-beta.tar.gz
bdc3a5ca87130520e93be58533a6d8bb40f709716c87051d69572a5f077d12b5  lnd-linux-ppc64-v0.5-beta.tar.gz
792c3296b90fc8b71bd00e391e930a6563fd1725508d58c815e6a83eb52e23c9  lnd-netbsd-386-v0.5-beta.tar.gz
9cb9c93eb185439bbd8059b2bac083b9f2de2f23a2e73beac9d4c9697d8b1958  lnd-netbsd-amd64-v0.5-beta.tar.gz
b39325128b19863ed67653f41abca10c8412eeea216c4721cdec516df6ecf77a  lnd-openbsd-386-v0.5-beta.tar.gz
9e545e29252559173866e037e08b4b94425d9acb82d0701da001d51815773857  lnd-openbsd-amd64-v0.5-beta.tar.gz
1bd6a2738de0d3408d8eff5e1a345eee0712553f72352fefe0ee1af133811218  lnd-windows-386-v0.5-beta.zip
c6d4b1a54338753a808c6cd3c23da4a840e1dab6aafd58030fe1a5e81a6d7e5d  lnd-windows-amd64-v0.5-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-beta

This release can also be found in roasbeef's public keybase folder.

After go1.12 is released, we'll be switching to a method in order to allow deterministic builds to allow for third party verifiability of the binaries included in this release.

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

Notable Changes

Switch to Mainline btcsuite Libraries

With this release of lnd, the project no longer uses roasbeef's set of forks for the btcsuite family of libraries such as btcd, and btcutil. The old set of forks will no longer be maintained as all development will now be focused on mainline btcsuite. Additionally, roasbeef is now a maintainer of the btcsuite set of libraries. As a result, we'll be able to easily integrate any new feature or bug fixes we need to btcsuite directly, rather than maintaining our own fork again. As a result, we recommend that those users running lnd with a btcd upgrade to the latest versions of the master branch of btcd.

txindex For Full Node Backends is Now Optional!

Before this release, if a user was running with any of the supported full node backends we required them to run with the transaction index active. With this version of lnd, [running a full node backend with a transaction index is no...

lnd v0.5-beta-rc2

This release marks the 5th major release release of lnd: v0.5-beta! This release marks a massive step in the robustness and reliability of lnd as a routing node daemon for the Lightning Network. Additionally, a number of optimizations have been implemented which will reduce the memory and CPU footprint of lnd making it more amendable to run on smaller devices like Raspberry Pis and also eventually mobile phones! A number of bug fixes related to reliable HTLC forwarding, persistence recovery, and path finding have also landed in this release. As a result users should generally find path finding to be a smoother experience, and should find that lnd is able to recover from a number of partial and complete failures in routine protocol exchanges.

The 0.5-beta release doesn't include any strictly breaking changes. So a result, users should find the upgrade process to be smooth. If one is upgrading from 0.4.2, the initial starting logs should look something like:

2018-08-29 01:50:42.690 [INF] LTND: Version 0.5.0-beta commit=73af09a06ae9cd5ba92a376e8253ae5450fe09cc
2018-08-29 01:50:42.690 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2018-08-29 01:50:42.925 [INF] CHDB: Checking for schema update: latest_version=5, db_version=0
2018-08-29 01:50:42.925 [INF] CHDB: Performing database schema migration
2018-08-29 01:50:42.925 [INF] CHDB: Applying migration #1
2018-08-29 01:50:43.100 [INF] CHDB: Populating new node update index bucket
2018-08-29 01:50:45.345 [INF] CHDB: Populating new edge update index bucket
2018-08-29 01:51:19.532 [INF] CHDB: Migration to node and edge update indexes complete!
2018-08-29 01:51:19.532 [INF] CHDB: Applying migration #2
2018-08-29 01:51:19.613 [INF] CHDB: Migrating invoice database to new time series format
2018-08-29 01:51:19.613 [INF] CHDB: Migration to invoice time series index complete!
2018-08-29 01:51:19.613 [INF] CHDB: Applying migration #3
2018-08-29 01:51:19.613 [INF] CHDB: Migrating invoice database to new outgoing payment format
2018-08-29 01:51:19.613 [INF] CHDB: Migration to outgoing payment invoices complete!
2018-08-29 01:51:19.613 [INF] CHDB: Applying migration #4
2018-08-29 01:51:57.457 [INF] CHDB: Migration of edge policies complete!
2018-08-29 01:51:57.457 [INF] CHDB: Applying migration #5
2018-08-29 01:51:57.458 [INF] CHDB: Migrating database to support payment statuses
2018-08-29 01:51:57.458 [INF] CHDB: Marking all known circuits with status InFlight
2018-08-29 01:51:57.458 [INF] CHDB: Marking all existing payments with status Completed
2018-08-29 01:51:57.458 [INF] CHDB: Migration of payment statuses complete!

One lncli related change that users running on simnet or testnet will notice is that the default location for macaroons has now changed. As a result, lnd will generate a new set of macaroons after it has initially been upgraded. Further details will be found below, but lnd will now generate a distinct set of macaroons for simnet, testnet, and mainnet. As a result, you may need to supply additional arguments for lncli to have it work as normal on testnet like so:

lncli --network=testnet getinfo

or

lncli --chain=litecoin --network=testnet getinfo

In order to cut down on the typing one needs to go through, we recommend creating an alias like so:

alias tlncli=lncli --network=testnet

NOTE: In this release, the --noencryptwallet command line and config argument to lnd has been phased out. It has instead been replaced with an argument identical in functionality, but distinct in naming: --nowalletseed. The rationale for this change is to remove the foot gun that was the prior config value, as many users would unknowingly create mainnet nodes using the argument. This is dangerous, as if done, the user wouldn't receive a recovery mnemonic to recover their on-chain funds in the case of disaster. We've changed the name of the argument to better reflect the underlying semantics.

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 roasbeef's key if you haven't done so already:

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

The keybase page of roasbeef includes several attestations across distinct platforms in order to provide a degree of confidence that this release was really signed by "roasbeef".

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

gpg --verify manifest-v0.5-beta-rc2.txt.sig

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):

0e7b733346734882f52f635c1d76473f9d2eda045a581c4c42e67d3044f04de6  lnd-darwin-386-v0.5-beta-rc2.tar.gz
73b6cecf56cfd7895890aea2e5dee5ea56e521f6cc65f8cea5482dfe94fd984a  lnd-darwin-amd64-v0.5-beta-rc2.tar.gz
cda6e9399a6b3dc447d2ccaf6679b3affc4220619c9d1aa859fd5a915abc97ce  lnd-dragonfly-amd64-v0.5-beta-rc2.tar.gz
ae4df8a4f871f9bf57498084ed3939eb4f7bf108c573ff85bf50023f655492eb  lnd-freebsd-386-v0.5-beta-rc2.tar.gz
7c21b6db971550bd6fe182d79b79028cf10fa41ddeeb856adb6369fd9d036e95  lnd-freebsd-amd64-v0.5-beta-rc2.tar.gz
b65c1b5bbfce0d2491e9a0a84924b7b975f789142bd4449ef073ca4d49b2db4e  lnd-freebsd-arm-v0.5-beta-rc2.tar.gz
60254c1ce30dc08faa68b87cd29264fc36eb27fad1bc7f6b15d80b1fe176a09d  lnd-linux-386-v0.5-beta-rc2.tar.gz
1ae4bd6a30f0bb4a4077fc40c3782a27ec48dcc41bb96f9faa8f56506f3a4fc3  lnd-linux-amd64-v0.5-beta-rc2.tar.gz
d82eb2ee2cd89d0689ed4582ad9803700f2db0d94449e2c7b239be05a133c899  lnd-linux-arm-v0.5-beta-rc2.tar.gz
4b26f06cc3d9f8a1aefeefb5399ac45ec693a719c0f3a39a42b582213022816a  lnd-linux-arm64-v0.5-beta-rc2.tar.gz
eac9ae87925c5b1bc1b7235a720992aa202a61aed789e8e235d2dd1d525e4ef3  lnd-linux-mips64-v0.5-beta-rc2.tar.gz
d9cdfa8655bf3dd8e32104d635532d71519cf4fb0f6e87a0c3fa590562273087  lnd-linux-mips64le-v0.5-beta-rc2.tar.gz
67a7004777d1a61c078ea2ed097adfa04c9184c6b909f0cefa6bddff14f7f752  lnd-linux-ppc64-v0.5-beta-rc2.tar.gz
c4ac913e6d516375516b8532d354e0cf242a2de5848aa868441a01078923ae5b  lnd-netbsd-386-v0.5-beta-rc2.tar.gz
b4727576bf1f453ef3261bc9fb65bc3b29c8949258818c1463bf21935d867712  lnd-netbsd-amd64-v0.5-beta-rc2.tar.gz
9369d62931dbd6977ad73e92add97960f63bdea97b55fa3d017a42db7b38d520  lnd-openbsd-386-v0.5-beta-rc2.tar.gz
f95a56223eb00ded888c22723cb662d9c827607d7880b01fb65daf565026d428  lnd-openbsd-amd64-v0.5-beta-rc2.tar.gz
15ee42130313fbfe81f5090064a26268bb21e3deba063f895d6e582fe84fd5d4  lnd-windows-386-v0.5-beta-rc2.zip
ad985b635651d59b74628d3f9e9bce7c17643c7326030b286246b6fe5a70d4ed  lnd-windows-amd64-v0.5-beta-rc2.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-beta-rc2

You should see the following if the verification was successful:

gpg: Signature made Wed Sep  5 21:41:45 2018 PDT
gpg:                using RSA key 65317176B6857F98834EDBE8964EA263DD637C21
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

After go1.12 is released, we'll be switching to a method in order to allow deterministic builds to allow for third party verifiability of the binaries included in this release.

This release can also be found in roasbeef's public keybase folder.

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

Notable Changes

Switch to Mainline btcsuite Libraries

With this release of lnd, the project no longer uses roasbeef's set of forks for the btcsuite family of libraries such as btcd, and btcutil. The old set of forks will no longer be maintained as all development will now be focused on mainline btcsuite. Additionally, roasbeef is now a maintainer of the btcsuite set of libraries. As a result, we'll be able to easily integrate any new feature or bug fixes we need to btcsuite directly, rather than maintaining our own fork again. As a result, we recommend that those users running lnd with a btcd upgrade to the latest versions of the master branch of btcd.

txindex For Full Node Backends is Now Optional!

Before this release, if a user was running with any of the supported full node backends we required them to run with the transaction index active. With this version of lnd, running a full node backend with a transaction index is now optional! As a result, if a user wishes to run a lighter version of their full node without the transaction index, then they're able to do so. However, for performance reasons until the persistent height hints are re-activated, we recommend running with an active transaction index for your full node which backs lnd. In either case, lnd will automatically detect if the backing full node has an active transaction index and act accordingly.

Future releases of lnd will allow for even lighter full node configuration by supporting pruned nodes as a first class citizen.

Neutrino BIP 157+158 Compliance and Optimizations

This release of lnd contains several bug fixes, and optimizations for the neutrino li...