Releases: lightningnetwork/lnd
lnd v0.7.0-beta-rc1
This release marks a new major release of lnd that includes several important bug fixes, an improved payment API, pathfinding enhancements, faster initial sync times, support for fee bumping on sweeps, and an initial rollout of altruistic watchtowers. As always, users are highly encouraged to upgrade to this new version.
Database migrations
This version includes two migrations, the first is in channel.db which modifies the structure of the payment tracking data to support the refactored router and its ability to reliably display payments via the RPC. The migration should look like this:
2019-06-14 21:54:53.576 [INF] LTND: Version: 0.7.0-beta commit=v0.7.0-beta-rc1, build=production, logging=default
2019-06-14 21:54:53.579 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2019-06-14 21:54:53.583 [INF] CHDB: Checking for schema update: latest_version=9, db_version=8
2019-06-14 21:54:53.586 [INF] CHDB: Performing database schema migration
2019-06-14 21:54:53.586 [INF] CHDB: Applying migration #9
2019-06-14 21:54:53.586 [INF] CHDB: Migrating outgoing payments to new bucket structure
2019-06-14 21:54:53.586 [INF] CHDB: Migration of outgoing payment bucket structure completed!
The second migration is in wallet.db, which prunes redundant block data already being stored by the underlying backend. The migration should look like this:
2019-06-14 21:54:53.744 [INF] LNWL: Applying wallet address manager migration #8
2019-06-14 21:54:53.746 [INF] LNWL: Removing block hash entries beyond maximum reorg depth of 10000 from current tip 580748
Once updated, it will not be possible to return to an older version of lnd.
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/bitconner/pgp_keys.asc | gpg --import
Once you have the required PGP keys, you can verify the release (assuming manifest-v0.7.0-beta.txt and manifest-v0.7.0-beta.txt.sig are in the current directory) with:
gpg --verify manifest-v0.7.0-beta.txt.sig
You should see the following if the verification was successful:
gpg: assuming signed data in 'manifest-v0.7.0-beta-rc1.txt'
gpg: Signature made Fri Jun 14 14:24:37 2019 PDT
gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7
gpg: Good signature from "Conner Fromknecht <conner@lightning.engineering>" [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):
a0af101b730d3f30cb85d46ce9b70f639ed845318deb72f08196714974a9a4f7 lnd-darwin-386-v0.7.0-beta-rc1.tar.gz
2385d2dcdcf2df7623d51611074968ecc575943e7fd06e0c31821d4454ff1cc4 lnd-darwin-amd64-v0.7.0-beta-rc1.tar.gz
ba584ff4528b7a8e91785c2b53258fcae795d8faa2ab5f71b74a0111ac1ea885 lnd-dragonfly-amd64-v0.7.0-beta-rc1.tar.gz
e19ee77f5c680b3dd9cdd9286273ae076f653e31a930ec2e268ac38a2102c11a lnd-freebsd-386-v0.7.0-beta-rc1.tar.gz
210f1977bd9e6c1904a9ef215575e7ec43bb52775d04f7e431d9919c1df3c31c lnd-freebsd-amd64-v0.7.0-beta-rc1.tar.gz
4a1b7783e928ac56887b874851595983e62414a95e67bbd422052a7a75b4a760 lnd-freebsd-arm-v0.7.0-beta-rc1.tar.gz
034570245b113074d9b1ccaf6f74b5fe16d2cd06ba97fe357cd8d77dd3d2f744 lnd-linux-386-v0.7.0-beta-rc1.tar.gz
6cb52c42c6b837b8dda35124cb74c591b3f9167f92e73d0e3ea46b359cb5bdf4 lnd-linux-amd64-v0.7.0-beta-rc1.tar.gz
5f4666a9c12e578c41faea4868cd5ea447dfa0e80ce7a282eced36e1205df968 lnd-linux-arm64-v0.7.0-beta-rc1.tar.gz
0573093e4d84213941adab88cc5cd604f9b3e1344a28bb7b8894d2302fa05022 lnd-linux-armv6-v0.7.0-beta-rc1.tar.gz
24f4860d44d726a0e2fb14c5a368d521637b9ecc009b552a8ce987b0b28f3544 lnd-linux-armv7-v0.7.0-beta-rc1.tar.gz
4ea4e15e4b15c8c2ad86590c30315200090dcb74173448e394e3e4e4dae78415 lnd-linux-mips64-v0.7.0-beta-rc1.tar.gz
4bc989aececec53c42f8d8338e3f25358b0e05de94223259f6222b6230a1c498 lnd-linux-mips64le-v0.7.0-beta-rc1.tar.gz
876996e045ad241b594048223069be2f96dc8c4d46aaf81d7e3c47327c3b6ecc lnd-linux-ppc64-v0.7.0-beta-rc1.tar.gz
d402847b1efeb039aa72fbf20320df30161a7aa3dca54b09de4b29c8f499f03a lnd-netbsd-386-v0.7.0-beta-rc1.tar.gz
4cb2996dfb5fa42a9a771f0631631f102080512d406d942d5816ecc9c1d5705e lnd-netbsd-amd64-v0.7.0-beta-rc1.tar.gz
4e7dd42d39e81cdbfb2de14f67415e0c3c986eeaa7d9ed9ec029b7d6bf963f73 lnd-openbsd-386-v0.7.0-beta-rc1.tar.gz
8bf0514c74d80584d87544f07a2e520ca9311ef7a1a6e42e9029ac8fcb3b533b lnd-openbsd-amd64-v0.7.0-beta-rc1.tar.gz
f13d1628ccba4bc963e7ed2a81be0ed0cd6c9c11ea71a4a7a68a4ff01d2a4d0b lnd-source-v0.7.0-beta-rc1.tar.gz
04b0768147197846603a0465b962c6fec3dfb315e3b446b0d148620a81e8266c lnd-windows-386-v0.7.0-beta-rc1.zip
1a9ee1d3e30e69e14cb00ef982e0a63d05ed39f74e3fc7d3a16b31efe8685a89 lnd-windows-amd64-v0.7.0-beta-rc1.zip
21098c814a77dfdff0bf53329f8337ee69b49fa27829507402934a60147a9dcc 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.7.0-beta
The binaries are compiled with go1.12.6 and include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, and routerrpc.
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.7.0-beta.tar.gz are in the current directory:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.7.0-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.7.0-beta" ./cmd/lnd
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.7.0-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
⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️
Release Notes
Coming soon...
Changelog
The full list of changes since 0.6.1-beta can be found here:
Contributors (Alphabetical Order)
AdamISZ
chokoboko
Conner Fromknecht
Daniel McNally
Federico Bond
Francisco Calderón
Geoff Taylor
Johan T. Halseth
John Griffith
Joost Jager
Matt Drollette
michael1011
Neevai Esinly
Olaoluwa Osuntokun
Turtle
Valentine Wallace
Wilmer Paulino
Xavi Soler
Yaacov Akiba Slama
lnd v0.6.1-beta
Roasbeef
Olaoluwa Osuntokun
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 <laolu32@gmail.com>" [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, theSyncManager'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 <laolu32@gmail.com>" [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.
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
Roasbeef
Olaoluwa Osuntokun
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 <laolu32@gmail.com>" [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.
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
Roasbeef
Olaoluwa Osuntokun
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 <laolu32@gmail.com>" [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
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
Roasbeef
Olaoluwa Osuntokun
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 RPCNewWitnessAddresshas been removed. Since we are only using witness addresses, addresses can be fetched usingNewAddress.
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...
lnd v0.5.1-beta-rc1
halseth
Johan T. Halseth
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
lnclirelated change that users running onsimnetortestnetwill notice is that the default location for macaroons has now changed. As a result,lndwill generate a new set of macaroons after it has initially been upgraded. Further details will be found below, butlndwill now generate a distinct set of macaroons forsimnet,testnet, andmainnet. As a result, you may need to supply additional arguments forlnclito have it work as normal ontestnetlike so:lncli --network=testnet getinfoor
lncli --chain=litecoin --network=testnet getinfoIn order to cut down on the typing one needs to go through, we recommend creating an alias like so:
alias tlncli=lncli --network=testnetNOTE: In this release, the
--noencryptwalletcommand line and config argument tolndhas 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
bitcoindbackend 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 oldbitcoind.zmqpathentry inlnd.conf, and, for example, replace it with:bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332 bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333Also ensure that
bitcoindis exposing distinct ZMQ ports inbitcoin.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 <laolu32@gmail.com>" [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...