Releases: lightningnetwork/lnd
lnd v0.8.0-beta-rc3
lnd v0.8.0-beta-rc3
lnd v0.8.0-beta
Database Migrations
This release includes two migrations. The first migration upgrades existing payment attempts and results to support the new TLV onion format. The migration should look like this:
2019-09-26 15:37:31.794 [INF] CHDB: Checking for schema update: latest_version=11, min_upgrade_version=9, db_version=9
2019-09-26 15:37:31.794 [INF] CHDB: Performing database schema migration
2019-09-26 15:37:31.794 [INF] CHDB: Applying migration #10
2019-09-26 15:37:31.795 [INF] CHDB: Migration of route/hop serialization complete!
2019-09-26 15:37:31.795 [INF] CHDB: Migrating to new mission control store by clearing existing data
2019-09-26 15:37:31.795 [INF] CHDB: Migration to new mission control completed!
The second migration upgrades invoices to support tracking multiple HTLCs, rather than a single one. This increases the accuracy of invoice accounting within lnd across restarts. Note that you cannot update if you have any pending hodl invoice. The migration should look like this:
2019-09-26 15:37:31.795 [INF] CHDB: Applying migration #11
2019-09-26 15:37:31.795 [INF] CHDB: Migrating invoices to new invoice format
2019-09-26 15:37:31.795 [INF] CHDB: Migration of invoices completed!
Once these migrations succeed, it will not be possible to return to a prior 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.8.0-beta.txt and manifest-v0.8.0-beta.txt.sig are in the current directory) with:
gpg --verify manifest-v0.8.0-beta.txt.sig
You should see the following if the verification was successful:
gpg: assuming signed data in 'manifest-v0.8.0-beta.txt'
gpg: Signature made Tue Oct 22 15:45:18 2019 PDT
gpg: using RSA key 4AB7F8DA6FAEBB3B70B1F903BC13F65E2DC84465
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]
That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.
Verifying the Release Binaries
As of this release, our release binaries are fully reproducible thanks to go1.13! Third parties are now able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.13.3, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.
Finally, you can also verify the tag itself with the following command:
git verify-tag v0.8.0-beta
Building the Contained Release
Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.8.0-beta.tar.gz are in the current directory, follow these steps:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.8.0-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.8.0-beta" ./cmd/lnd
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.8.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" ./build/release/release.sh
⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️
Release Notes
Protocol Upgrades
Multi-Frame TLV Based Onion
In this release of lnd, we’ll now by default signal adherence to the new multi-frame TLV based onion format used when routing HTLCs end to end within the network. Compared to the legacy format, this format is much more flexible as rather than using a handpacked encoding for each field, we’ll now transmit TLV (type-length-value) streams, which is essentially a key-value map. As a result, the onion format is now far more extensible, as we can easily add new types without triggering a network wide update. In many instances (such as AMP), only the sender and receiver need to know of the new information in the onion, streamlining upgrade paths.
This change isn’t exposed to developers yet, but will be in future versions, allowing them to send a small amount of bytes to the receiver alongside a payment. The largest impact of this new feature is to lay the groundwork for the AMP/MPP work that has begun. In the case of AMP, this new namespace in the onion will be used for things like sending a partial payment shard, the total amount of the unified set of payments, and so on. We’ll also leverage this space to roll out our spontaneous payment feature (keysend) in a future version of lnd.
Safu Commitments (option_static_remote_key)
Another major protocol update that has shipped in this new version of lnd is something we call “safu commitments”. This new commitment format represents a large step in making Lightning safer to use for end users. Before this change, if the remote party forced closed the channel on-chain, in order to sweep your funds (in the case of partial data loss, but SCB existence), then the party that lost data would need to obtain a random nonce from the other party in order to sweep their funds. This dependency at times made recovery very difficult, or even indeterminate, if the party that lost data was unable to obtain this per-state nonce from the remote party.
With this new commitment format, we’ve instead removed this nonce derivation from the commitment output. Instead, when the remote party force closes, the funds will go directly into one’s wallet. As a result, the only thing required to recover funds in the case of partial data loss now are one’s SCB and the on-chain event of the channel being confirmed on chain. A new SCB version (v1) has been added to signal if the channel being backed up uses the old or new commitment format, allowing us to keep our recovery flow identical to the current one.
It’s important to note that in order to use this new commitment format, new channels must be opened. The SCBs stored on disk, as well as those that are sent over the various RPC calls, will be automatically updated to reflect if this new commitment is being used in the channels being backed up. A new field has been added to the ListChannels output (static_remote_key) that indicates if the channel is using the new safu commitment format or not.
TLV Serialization Library
This release also includes a new TLV serialization library, which implements the TLV format described in BOLT 01. The tlv package produces encodings that are both forwards and backwards compatible, and will form the basis of making wire messages and onion payloads easily extensible fields for new features like MPP, AMP, or extended gossip queries.
BOLT 11 Feature Bits
In 0.8.0, lnd now supports the ability to generate and parse invoices with payment-specific feature bits. At the moment there are no such feature bits that are advertised, however this is a preliminary step in order to widely deploy the parsing logic for when this happens. The first candidate features for being advertised are likely for MPP or AMP, which can inform the sender as to whether they may pay a particular invoice using those payment methods. In theory, the sender can also require that an invoice be fulfilled with a particular payment type.
Indefinite Channel Reestablishment
Prior to 0.8.0, lnd would give the remote peer 30 seconds to send a their channel_reestablish message. Typically this duration was sufficient, however if the exchange was not completed in a timely manner lnd would incorrectly escalate this into a protocol error, and cause strict implementations to force close the channel.
In one instance with a c-lightning node, this resulted in 40 channels being force closed, since the contention at startup prevented the remote node from promptly sending channel_reestablish. In 0.7.2, c-lightning also added mitigations to avoid this situation, by [spacing out reconnections to peers on startup](https://github.com/...
lnd v0.8.0-beta-rc2
wpaulino
Wilmer Paulino
v0.8.0-beta-rc2
lnd v0.8.0-beta-rc1
wpaulino
Wilmer Paulino
v0.8.0-beta-rc1
lnd v0.7.1-beta
This marks the first minor release in the v0.7.0 series. There are no database migration in this release. Instead, this release contains a number of optimization, bug fixes, slight RPC interface tweaks, and some minor features.
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.1-beta.txt and manifest-v0.7.1-beta.txt.sig are in the current directory) with:
gpg --verify manifest-v0.7.1-beta.txt.sig
You should see the following if the verification was successful:
gpg: assuming signed data in 'manifest-v0.7.1-beta.txt'
gpg: Signature made Thu Jul 25 16:56:33 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):
e4e347076f924c0b9800ca6ebe534ddc3994054df129ad55e14590a958a17825 lnd-darwin-386-v0.7.1-beta.tar.gz
bd2ce2df54d08df4e2c48ec26954946a1e05e2385efce2d40fbe952b20e237f3 lnd-darwin-amd64-v0.7.1-beta.tar.gz
f2e3b6a7bc4b1725fa81c6795919aad39c363cdb18763974a2691934f13809d4 lnd-dragonfly-amd64-v0.7.1-beta.tar.gz
57021bdab4693b16c7bc5afcbcde4ed31edebb1e0f4a4b1fa327d337f4001bd0 lnd-freebsd-386-v0.7.1-beta.tar.gz
95d263659a39e891986b121924c6c701218a390ecb04fb6898466b2f3da844af lnd-freebsd-amd64-v0.7.1-beta.tar.gz
6c16d14d5514093ff9495c5ad56ccd2fea1585a38ed8ee078d75ce9838d4c8f7 lnd-freebsd-arm-v0.7.1-beta.tar.gz
273c21b7a6900ca91f3f09a9d8753cb0c0a549d8ac81fdc3748c1292141b5133 lnd-linux-386-v0.7.1-beta.tar.gz
8a7dcf0cdb1c3dda1f9936625f74644ee0b58940970f2025935590952be8d7ba lnd-linux-amd64-v0.7.1-beta.tar.gz
755c505c48af1531f784cbff1fa62424c7831698433889680fd2f6030fc15f76 lnd-linux-arm64-v0.7.1-beta.tar.gz
afd3384adaf1adf7545ae7c47cf274532b5cda8cab547c2cc6fc65d21a52d231 lnd-linux-armv6-v0.7.1-beta.tar.gz
a8c5199fdad4a900ce2dc70d9de08e303235e796bf960d1a07f803f837c086da lnd-linux-armv7-v0.7.1-beta.tar.gz
f657f914bc9a5fd4ebaa65ee4e94fac03e8b03fe59e193972e1038b4b9399388 lnd-linux-mips64-v0.7.1-beta.tar.gz
e1d7133e27be8507381357f3478f1aadcb4d328e446a1981e3f2427739fc2bb1 lnd-linux-mips64le-v0.7.1-beta.tar.gz
b7b43f4bce9738d28d60b79f57778fb14b6180eeed9f3f731a3b7bd4169834cf lnd-linux-ppc64-v0.7.1-beta.tar.gz
366516b68d9e49775429ecd6c1971a2940c4c3e84421f59966342b45a44c5cf4 lnd-netbsd-386-v0.7.1-beta.tar.gz
eb9c83dca69696d195a5b98059f8aefb61e4522411ebc988bf25940adda6b570 lnd-netbsd-amd64-v0.7.1-beta.tar.gz
e7e70a835d4358e7357b19f857eb8ed2e05b3bf392aa0201016ac0e6282f4585 lnd-openbsd-386-v0.7.1-beta.tar.gz
10b0866377ef7452da4097596aa03afc42fcd2c037a3255e8e402a0bc04a1eea lnd-openbsd-amd64-v0.7.1-beta.tar.gz
ae8cb77eb7567ed9f8041a17eb6f65280cf81f4fbc3bf10eb671a423f62fc948 lnd-source-v0.7.1-beta.tar.gz
b68357ffd9d9527d04cb7d16534998711bca5948d7704c1439437c993f68b555 lnd-windows-386-v0.7.1-beta.zip
249378747307d7dff0d5da9b0ef8acc14908d18d4b5adddc68a66939432f4770 lnd-windows-amd64-v0.7.1-beta.zip
3bbfa000e2b4c7702f92d24235b5a098f37fd7b5830ca42586678f03d7cf9da3 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.1-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.1-beta.tar.gz are in the current directory:
tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.7.1-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.7.1-beta" ./cmd/lnd
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.7.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
⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️
Release Notes
Networking Payment Latency Improvements
We'll now pipeline HTLC pre-images across the route before each hop fully locks in the change. As a result, the network as a whole should now see dramatically reduced payment latency. Before this change, it would take 1.5 * N round trips (where N is the number of hops) for the sender of an HTLC to obtain a pre-image for a successful payment. With the prior logic, the pre-image would flow backwards in lock-step, with the receiver having it fully locked in first. With this new logic, it now only takes 0.5 * N RTT for the same operation. As a result, the sender of the payment will now get the pre-image much sooner, resulting in lower perceived payment latency. The higher the round trip latency between links, the more profound the speed up will be within the network.
Build
One of the dependencies required by lnd was being fetched from the author’s host rather than GitHub. At some point the host was down, causing new installations of lnd to fail. To resolve this, we’ve decided to use the author’s GitHub mirror of the dependency, which should provide a higher bar of reliability.
lncli Improvements
The help message for updatechannelpolicy has been updated to reflect the newly added ability to set fee rates to zero for channels.
We'll now confirm the aezeed pass phrase during initial wallet creation.
RPC Changes
The QueryRoutes command now has a new option UseMissionControl allowing it to tap into the central MissionControl path finding history. As a result, the command will now benefit from the path finding history of lnd as a whole, which means it'll now return more pertinent routes.
The ForwardingHistory command has been made easier to use by assuming an start+end time of within the past 24 hours. This makes the command easier to use both on the RPC level, and also on the command line.
An off-by-one error has been fixed in the AddInvoice call within the invoicerpc sub-server. This would at times caused lnd to add too many hop hints, making invoices invalid.
The payments returned from the ListPayments RPC included a fee field, indicating how many satoshis were paid in fees. This wasn’t consistent, as payments can have sub-satoshi fees. To address this, we’ve deprecated the existing fee field and have added two new ones to replace it: fee_msat and fee_sat. The existing fee field will likely be removed in a future release.
The channel reserve of each party within a channel is now shown through the ListChannels RPC. This provides applications building on top of lnd with finer granularity with regards to how much each party is allowed to send.
Payment related RPC calls in the new routerrprc sub-server have been extended to return richer error information. The SendPayment/SendToRoute calls will now also return the following concrete errors:
-
FailureReasonError: This is returned in case we get an unexpected response to our payment attempt for which it does not make sense to try different routes. -
FailureReasonIncorrectPaymentDetails: This is returned in case the payment hash is un...
lnd v0.7.1-beta-rc2
lnd v0.7.1-beta-rc2
lnd v0.7.1-beta-rc1
lnd v0.7.1-beta-rc1
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