Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 28 million developers.Sign up
- lnd-darwin-386-v0.5.1-beta.tar.gz 19 MB
- lnd-darwin-amd64-v0.5.1-beta.tar.gz 19.5 MB
- lnd-dragonfly-amd64-v0.5.1-beta.tar.gz 19.5 MB
- lnd-freebsd-386-v0.5.1-beta.tar.gz 19 MB
- lnd-freebsd-amd64-v0.5.1-beta.tar.gz 19.6 MB
- lnd-freebsd-arm-v0.5.1-beta.tar.gz 18.3 MB
- lnd-linux-386-v0.5.1-beta.tar.gz 19.1 MB
- lnd-linux-amd64-v0.5.1-beta.tar.gz 19.6 MB
- lnd-linux-arm64-v0.5.1-beta.tar.gz 18.3 MB
- lnd-linux-armv6-v0.5.1-beta.tar.gz 18.3 MB
- lnd-linux-armv7-v0.5.1-beta.tar.gz 18.3 MB
- lnd-linux-mips64-v0.5.1-beta.tar.gz 18.6 MB
- lnd-linux-mips64le-v0.5.1-beta.tar.gz 18 MB
- lnd-linux-ppc64-v0.5.1-beta.tar.gz 18.8 MB
- lnd-netbsd-386-v0.5.1-beta.tar.gz 18.9 MB
- lnd-netbsd-amd64-v0.5.1-beta.tar.gz 19.5 MB
- lnd-openbsd-386-v0.5.1-beta.tar.gz 18.9 MB
- lnd-openbsd-amd64-v0.5.1-beta.tar.gz 19.5 MB
- lnd-windows-386-v0.5.1-beta.zip 18.8 MB
- lnd-windows-amd64-v0.5.1-beta.zip 19.4 MB
- manifest-v0.5.1-beta.txt 1.98 KB
- manifest-v0.5.1-beta.txt.sig 566 Bytes
- manifest-v0.5.1-beta.txt.sig.halseth 310 Bytes
- Source code (zip)
- Source code (tar.gz)
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
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.
NewWitnessAddress: The RPC
NewWitnessAddresshas been removed. Since we are only using witness addresses, addresses can be fetched using
A few RPCs have changed their behavior slightly, see the the RPC changes section.
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
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.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@example.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 <firstname.lastname@example.org>" [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
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.
Height hint cache
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.
When sending a payment, there exists situation where the graph information the client has is not up to date with the nodes it is attempting to route through. In these cases the routing nodes will send an error back along with the updated information, such that the client can retry the payment with the correct parameters.
Previously we didn't check the signatures on this updated information, making it possible for nodes to respond with information for channels they didn't control. With an added validity check, this is no longer the case, and all graph information must be signed by the controlling parties.
A new RPC has been added for debug builds, that let users forcefully remove channels from their databases. This must be used with caution, as all state for the targeted channels will be lost, essentially making it impossible to recover any funds kept in these channels. This RPC is added to let advanced users get rid of leftover channels from earlier versions of
lnd, where channels were not always cleaned up properly. Channels that had their funding transactions broadcast with a fee too small can also be removed with this RPC. To make sure no one uses this functionality by accident, it is only possible to use in debug builds.
A new package
build has been added to
lnd, greatly simplifying the process of adding build dependent changes, and improving logging during unit tests. The version string of
lnd will with this change include the version tag, commit hash and number of commits since the tag. Logs from unit tests can be inspected by passing
log="stdout <loglevel>" to
Smarter rate limiting
lnd will now rate limit peers that are requesting excessive amounts of data to avoid DOS attacks. Since there are still older nodes running on the network which are acting spammy during graph sync, these will quickly be rate limited. To make sure a single "bad peer" won't degrade the performance of the daemon, they are limited on a per-peer basis.
go 1.11 support
go version has been upgraded to
v1.11! The project now supports
go 1.10 and
gRPC for its RPC interface, making it easy to gain access to the functionality of
lnd from a wide set of languages. The
gRPC version used was due for an upgrade, and has been updated to
v1.15.0, up from
v1.5.2. You shouldn't be seeing any breaking changes with this upgrade.
Reject insane timelocks
We now check that forwarded payments don't impose a timelock that is too far in the future. Earlier an attacker willing to lock up his own funds could craft routes where funds got locked up for a very long time.
New sweep package
A new package
sweep has been introduced, intended to take care of all kinds of sweeps within
lnd, such as retrieving funds from closed channels. This is part of an ongoing effort to reduce the statefulness of funds sweeping, and be smarter about batching sweeps together in bigger transactions to save on chain fees.
When opening a channel to a peer on the network, you have the option to immediately send some funds as part of the opening process (what is called
push amount). For most users accepting incoming channels this is not a problem (hey, free money!), but some merchants have seen customers pushing funds to them by mistake, resulting in an annoying refund process. Now there's a new configuration option
--rejectpush that makes the node reject any incoming channels that include a push amount.
SendToRoute with private channels
SendToRoute is an RPC that is used by advanced users to send payments along custom paths. Previously it had the restriction that the edges used in these custom paths were known to
lnd. A new option
pub_key in the route description given to
lnd create the route without relying on the channel graph, making it possible to attempt payments even for channels unknown to
lnd, such as private channels. This works since the payment is encrypted with the given public key, and now all information needed to construct the payload can be supplied over the RPC.
- Deprecating untyped value fields: Since RPC fields are not always typed to indicate their unit, there has been confusion especially whether
millisatoshisare used for certain RPCs. Going forward fields should indicate their type (ending with
_msat), and you might see the existing, untyped fields getting deprecated.
DescribeGraphRPC is used to get a list of the current information found in the local graph, including all known nodes and channels. Earlier this would include information about private nodes and channels you knew about. With this recent change, the caller must explicitly set the
IncludeUnannouncedflag if it wishes this private information to be part of the output, to avoid this information being leaked involuntarily.
- Prevent spending unconfirmed funds by default: The
SpendUnconfirmedflag must now be set for the wallet to use unconfirmed inputs when opening channels.
- Reversed QueryInvoices consistency: When querying for an offset of invoices in the reverse order, we would earlier list the first available invoice found after this offset. This was inconsistent with the non-reversed case, and has been changed.
- Number of inactive channels in
GetInfoRPC call now shows the number of inactive channels in addition to the number of active.
The full list of changes since
0.5-beta can be found here:
Contributors (Alphabetical Order)
Carlos Garcia Ortiz
Johan T. Halseth