Releases: lightningnetwork/lnd
lnd v0.7.0-beta
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, 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/roasbeef/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.txt'
gpg: Signature made Tue Jul 2 09:46:47 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):
f8452608ff2e3ca6a0327c830f2fee5e837b5a39e0bf7cedd190857a5b8894f8 lnd-darwin-386-v0.7.0-beta.tar.gz
57a2eef7c337dbad6bbdc2bdffe459292d34ce354b58d74e74b329753dc134c8 lnd-darwin-amd64-v0.7.0-beta.tar.gz
c7cd6a1f4980fbefaf4acc49940332d3159b7b6af989afb9d0c211abe0208d53 lnd-dragonfly-amd64-v0.7.0-beta.tar.gz
8380e5944053f5a8255deb0f69b3dc0a2bac30402b82abec9f348cad53ec166f lnd-freebsd-386-v0.7.0-beta.tar.gz
c818c3a983167312f3bf2c84cb285212c5052131319caaef287a97541d2ff479 lnd-freebsd-amd64-v0.7.0-beta.tar.gz
a1e861f4c9a4cf056030f40debd882c6f34502821d0edca27f415dcfbb9f7d8c lnd-freebsd-arm-v0.7.0-beta.tar.gz
47be6c3391fadbc5a169fa1dd6dd13031d759b3d42c71a2d556751746b705c48 lnd-linux-386-v0.7.0-beta.tar.gz
2e7ed105b9e57103645bda30501cbf3386909cfed19a2fabcc3dc9117ce99a8f lnd-linux-amd64-v0.7.0-beta.tar.gz
c995fa67d6b23e547723801de49817dda34188fba78d0fe8ae506774e54c0afd lnd-linux-arm64-v0.7.0-beta.tar.gz
a653b66e28b30131c9b766989cb490013128022e047273f287bf0f42a19693b9 lnd-linux-armv6-v0.7.0-beta.tar.gz
ac51d96ee9b57bfcab0b05dbcfcd9ce3bd42a216354c0972e97c1a1c86c2479a lnd-linux-armv7-v0.7.0-beta.tar.gz
a4a119855e3759e49472d7d0f1f8529e984e7e7fbcedb78463daf4d7f6aceb6e lnd-linux-mips64-v0.7.0-beta.tar.gz
2e06c33c0c8c4f6ef680071095e652ea0b32ff164545a60aa372de3b12644db1 lnd-linux-mips64le-v0.7.0-beta.tar.gz
6d4bc470ae424bf46f1057149880f60a83057f26693f0098f3e9dd774355cdcd lnd-linux-ppc64-v0.7.0-beta.tar.gz
d931981d6a742b07abc965e779fd8ed93a7dfdbbdeefea0a47b0cdf90a94b645 lnd-netbsd-386-v0.7.0-beta.tar.gz
db6d6be0cf5e7e791be097de944261db74ef1400b711dc6b825b21b7d3a2958f lnd-netbsd-amd64-v0.7.0-beta.tar.gz
0ef5470c6ba928e740bf83ba86b7af05eb0df0d3077e92c347fb93cdcf7fb276 lnd-openbsd-386-v0.7.0-beta.tar.gz
ec8dae2c01d818a6cbc622b07f5be8a4355a25cc7a887216edc232c528257c20 lnd-openbsd-amd64-v0.7.0-beta.tar.gz
d5d9178178dca9a3e770dc74d655f579e6aafaec9e7b32a726c44dc093c52aa0 lnd-source-v0.7.0-beta.tar.gz
254ccdf63c2dbd95381663be0e132d60f3423c9568d304a4384823c198d12f8a lnd-windows-386-v0.7.0-beta.zip
51badb5f690e8bc15e90331a42ea823399d1eb60708c4d682683f070ece13c23 lnd-windows-amd64-v0.7.0-beta.zip
4ee8e4b7d8372c8e750125dcdd93cd1b1b55687460a2f7fe1c8a23e60bb17e7b 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 (in progress)
bitcoind 0.18 compatibility
This new version of lnd has updated the way we check for errors over the RPC interface after we broadcast a transaction to be compatible with bitcoind v0.18. Note that the “master” branch of bitcoind isn’t yet supported yet as it includes distinct RPC changes to sendrawtransaction in particular that will require further updates in lnd. We’re targeting lnd v0.7.1. to fix these remaining RPC compatibility issues.
Private Altruist Watchtowers
In this release, we’re rolling out the ability to run a private, altruist watchtower as a fully-integrated subsystem of lnd. Watchtowers act as a second line of defense in responding to malicious or accidental breach scenarios in the event that client’s node is offline or unable to respond at the time of a breach, offering greater degree of safety to channel funds.
In contrast to a reward watchtower which demand a portion of the channel funds as a reward for fulfilling its duty, an altruist watchtower returns all of the victim’s funds (minus on-chain fees) without taking a cut. Reward watchtowers will be enabled in a subsequent release, though are still undergoing further testing and refinement.
In addition, lnd can now be configured to operate as a watchtower client, backing up encrypted breach-remedy transactions (aka. justice transactions) to other altruist watchtowers. The watchtower stores the fixed-size, encrypted blobs and is only able to decrypt and publish the justice transaction after the offending party has broadcast a revoked commitment state. Client communications with a watchtower are encrypted and authenticated using ephemeral keypairs, mitigating the amount of tracking the watchtower can perform on its clients using long-term identifiers.
Note that we have chosen to deploy a restricted set of features in this release that can begin to provide meaningful security to lnd users. Many more watchtower-related features are nearly complete or have meaningful progress, and we will continue to ship them as they receive further testing and become safe to release.
Configuring a Watchtower
To set up a watchtower, command line users should compile in the optional watchtowerrpc subserver, which will offer the ability to interface with the tower via gRPC or lncli. The minimal configuration needed to activate the tower is watchtower.active=1.
B...
lnd v0.7.0-beta-rc3
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-rc3, 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-rc3.txt and manifest-v0.7.0-beta-rc3.txt.sig are in the current directory) with:
gpg --verify manifest-v0.7.0-beta-rc3.txt.sig
You should see the following if the verification was successful:
gpg: assuming signed data in 'manifest-v0.7.0-beta-rc3.txt'
gpg: Signature made Sat Jun 29 15:00:20 2019 PDT
gpg: using RSA key 9C8D61868A7C492003B2744EE7D737B67FA592C7
gpg: Good signature from "Conner Fromknecht <[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):
bb7ef26ed0a8dfa31f6bd2016d87a5f28db0bba1b5c1cf203c2fda23bbdbe215 lnd-darwin-386-v0.7.0-beta-rc3.tar.gz
41d48f7f0cedcf7b212ace6a34ad4679eb9130c2abc8bf21e9367e08f852d22e lnd-darwin-amd64-v0.7.0-beta-rc3.tar.gz
a754be7b37456f998c898bd9db31247f35897a5fed9ddaaba2e9a9db6e07c869 lnd-dragonfly-amd64-v0.7.0-beta-rc3.tar.gz
96c756ac172415eb852b65f5fce58ea03adde85aa55ba53708b6dda079e1285f lnd-freebsd-386-v0.7.0-beta-rc3.tar.gz
4c6f8534d09ebf5a9227a4d272aba88e860f81543a8c4035cccf45e3742ea998 lnd-freebsd-amd64-v0.7.0-beta-rc3.tar.gz
ae6c6f7068b1b05a9a2536f97da497b8c8de27703d482644d4779b88bf97cc0f lnd-freebsd-arm-v0.7.0-beta-rc3.tar.gz
2723ce9dff50a2b063ba01b2b2cf4159db5aed5ade76a20978dfac361152fa06 lnd-linux-386-v0.7.0-beta-rc3.tar.gz
d90bf078edc57f12cfebfae96aaa6d686a8036a3cb1b8684855f773edd9f2ec7 lnd-linux-amd64-v0.7.0-beta-rc3.tar.gz
a0f40ec55ac9a9898657ede6084b32ae150d2d0483975eb1a6aab3c5fa691f2d lnd-linux-arm64-v0.7.0-beta-rc3.tar.gz
d6f993aa68d02bc2ee10445e28ba6133fa903a1dae45121581f48585fa60aa40 lnd-linux-armv6-v0.7.0-beta-rc3.tar.gz
92d2cf564714057ebf63f952454e4255e3e16e590178d096f75efc40931ace9a lnd-linux-armv7-v0.7.0-beta-rc3.tar.gz
3e11af4a161ffc0174718ab0f6e9bf6ade90acd92c0d6fbeaae10bf3471b8a6b lnd-linux-mips64-v0.7.0-beta-rc3.tar.gz
1932492a36d6ceacb1e073ebf68ee7e4b2a4bdccd26efbccec7d607d5a21cf3f lnd-linux-mips64le-v0.7.0-beta-rc3.tar.gz
0355917888200b4df575fe8d1600d0c3da591c7771cf0a240402a49e345a37b5 lnd-linux-ppc64-v0.7.0-beta-rc3.tar.gz
e9d7954589b6b7747d83f01b654828ae46cbff537e6d96e4732c43af61031ee6 lnd-netbsd-386-v0.7.0-beta-rc3.tar.gz
8e337e27269f50e3ed87de6649ae09d813d1e7dc6d0177555df138b07da664a6 lnd-netbsd-amd64-v0.7.0-beta-rc3.tar.gz
d1ab52fa7e454414476c6d6291802d44ef43bc0cb50e4c9169f01d1eee8d4547 lnd-openbsd-386-v0.7.0-beta-rc3.tar.gz
169bbfd8141fb41f29b4e68fd81463b7be460a411f11c8de91c9d6675617165d lnd-openbsd-amd64-v0.7.0-beta-rc3.tar.gz
97831392024dc17f35334d423d7905f400516e4a0f3623388b6a5c870d03914b lnd-source-v0.7.0-beta-rc3.tar.gz
1e05a93de75269f63c1019d2f0c36a9f85692253ee146e367cffb2cad1cae194 lnd-windows-386-v0.7.0-beta-rc3.zip
232bd9fad897d6a180ade63dc16a128751606ad87653fe0834cd2109c8b5754e lnd-windows-amd64-v0.7.0-beta-rc3.zip
bea687b821e4647f5a0228c25c4b5f25609a8fe47166f4cd0578ad09a849dbfb 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-rc3
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-rc3.tar.gz are in the current directory:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.7.0-beta-rc3.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.7.0-beta-rc3" ./cmd/lnd
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.7.0-beta-rc3" ./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 (in progress)
bitcoind 0.18 compatibility
This new version of lnd has updated the way we check for errors over the RPC interface after we broadcast a transaction to be compatible with bitcoind v0.18. Note that the “master” branch of bitcoind isn’t yet supported yet as it includes distinct RPC changes to sendrawtransaction in particular that will require further updates in lnd. We’re targeting lnd v0.7.1. to fix these remaining RPC compatibility issues.
Private Altruist Watchtowers
In this release, we’re rolling out the ability to run a private, altruist watchtower as a fully-integrated subsystem of lnd. Watchtowers act as a second line of defense in responding to malicious or accidental breach scenarios in the event that client’s node is offline or unable to respond at the time of a breach, offering greater degree of safety to channel funds.
In contrast to a reward watchtower which demand a portion of the channel funds as a reward for fulfilling its duty, an altruist watchtower returns all of the victim’s funds (minus on-chain fees) without taking a cut. Reward watchtowers will be enabled in a subsequent release, though are still undergoing further testing and refinement.
In addition, lnd can now be configured to operate as a watchtower client, backing up encrypted breach-remedy transactions (aka. justice transactions) to other altruist watchtowers. The watchtower stores the fixed-size, encrypted blobs and is only able to decrypt and publish the justice transaction after the offending party has broadcast a revoked commitment state. Client communications with a watchtower are encrypted and authenticated using ephemeral keypairs, mitigating the amount of tracking the watchtower can perform on its clients using long-term identifiers.
Note that we have chosen to deploy a restricted set of features in this release that can begin to provide meaningful security to lnd users. Many more watchtower-related features are nearly complete or have meaningful progress, and we will continue to ship them as they receive further testing and become safe to release.
Configuring a Watchtower
To set up a watchtower, command line users should compile in the optional watchtowerrpc subserver, which will offer the ability ...
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 <[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):
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
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, 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 <[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.
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.
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
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 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 <[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...