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
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.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@example.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):
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
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
-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
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! ⚡️⚡️⚡️
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.
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
Wallet Bug Fixes
The wallet will no longer rescan from the seed birthday if a wallet has no UTXOs once it has already been created.
Config and Wire Protocol Validation Fixes
A node's color is now properly validated when passed in as a config or command line parameter. This fix ensures that we're able to properly parse a hex color before attempting to commit it to the database. With this change, if an invalid color is passed, then
lnd will refuse to start.
We'll now validate our own node announcement as a sanity check to ensure generated announcements elsewhere in
lnd are fully protocol compliant.
We'll now properly avoid creating empty buckets within
bolt which have been the source of prior inadvertent bugs.
We'll now ensure that we don't accept any node announcements with an invalid alias.
A bug has been fixed wherein we'd encode an invalid (too long) length for the enclosed
ChannelUpdate within an onion error. This didn't affect
lnd nodes as we didn't rely on the encoded length when decoding the error payload. However, other implementations did, which rendered them unable to decode a sub-set of our onion error messages.
lnd will now reject (by default) requests for funding confirmations that we deem are too large.
A bug related to the
FeeUpdate message has been fixed which could at times cause two channels to de-synchronize.
lnd, will no longer send the
IncorrectHtlcAmount error. Instead, it will now use the new
UnknownPaymentHash error that includes the amount of the HTLC.
Network Level Channel Advertisements
All channels created by
lnd will now properly have the new
max_htlc field set. This is a prep for our upcoming AMP implementation. Payment splitting heuristics can use this value as a guide when determining payment chunk size, and nodes can use this value to control the largest payment shard they'll accept. In a future release, we'll make this value configurable over the RPC interface.
Payment Path Finding and Retries
We've modified our retry and search space pruning code when routing payments to be more consistent. The following issues has been fixed:
- If the channel update of
FailFeeInsufficient contains an invalid channel
id, it is not possible to properly add to the failed channels set.
FailAmountBelowMinimum may apply a channel update, but does not retry.
FailIncorrectCltvExpiry immediately prunes the vertex without
trying one more time.
A bug has been fixed to ensure that we get passed a non-nil route. Previously with unchecked usage of the
SendToRoute API, this may have caused a panic.
A change has been made to decouple the disabled bit from our local path finding. This is a preparatory step for an overhaul w.r.t the way we enable/disable channels, which is expected to land in 0.6.
RPC Interface Bug Fixes
We'll now properly validate the
ChannelPoint argument for the
CloseChannel RPC call. The
lncli command validates this field already, but a check was lacking in the main RPC pipeline as it assumed
lncli was being used.
Invoices that were created with hop hints will now show up as "private" within the output of
Additional validation has been added to ensure that it's no longer possible to attempt to force close a channel twice over the RPC interface. The second time wouldn't generate any new changes, but could at times unnecessarily block this second call.
Channels that are waiting to be opened, but which also have an unconfirmed closing transaction will now properly show up within
UnsettledBalance field in the
PendingChannels field will now properly be set.
False positives related to to showing a channel as
active have been located and patched.
HTLC Forwarding Fixes
We'll now properly return
FinalFailExpiryTooSoon rather than
FinalFailIncorrectCltvExpiry when the final hop of a route receives an HTLC expiry that's too soon.
In this version, we've made a full switch from
bbolt is the maintained fork of the original
bolt project. As it's maintained by CoreOS it actively has bug fixes land it in, which should increase the stability of our primary database.
We'll now scan backwards from the latest height back to the height hint when a sub-system needs to query for the unspentness of an output. This speeds up routine scans of recent channel closes as we no longer need to start from potentially months back in the past.
Rather than create a thread pool to generate/check signatures for the commitment updated protocol, we'll now use a global signature thread pool. This serves to reduce the total number of goroutines, idle CPU usage, and memory usage of
lnd for larger nodes.
The full list of changes since
0.5-beta can be found here:
Contributors (Alphabetical Order)
Chris Coverdale (ccdle12)
Johan T. Halseth