Release Notes
This release of Lightning Terminal (LiT) includes an LND version bump that addresses a few performance issues.
We'll be continuously working to improve the user experience based on feedback from the community.
This release packages LND v0.16.2-beta, Loop v0.23.0-beta, Pool v0.6.2-beta, and Faraday v0.2.11-alpha.
NOTE that the minimum version of lnd that can be used in --lnd-mode=remote is v0.16.0-beta.
Installation and configuration instructions can be found in the README.
Breaking API changes (for upgrading from a pre v0.9.0-alpha LiT version)
In previous versions of LiT, if run in integrated mode, LND's TLS certificate would be used by LiT meaning that users would need to use LND's TLS certificate when interacting with LiT's HTTP server. With this release of LiT, this behaviour has been changed. LiT will now always generate its own TLS certificate regardless of the mode it is running in. This means that users will need to point to LiT's TLS certificate when interacting with the HTTP server. More concretely, the remote.lit-tlscertpath and remote.lit-tlskeypath config options have been removed and replaced with tlscertpath and tlskeypath and when interacting with LiT through litcli, the lndtlscertpath and lndmode flags no longer need to be set.
Required changes when running in lnd remote mode (lnd-mode=remote)
When connecting to an existing lnd node, that node must enable the RPC middleware interceptor feature. You can enable that by specifying the --rpcmiddleware.enable command line flag or by adding rpcmiddleware.enable=true to your lnd.conf file. See the remote configuration docs for more information.
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 ellemouton's key from the ubuntu key server:
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 26984CB69EB8C4A26196F7A4D7D916376026F177
Once you have his PGP key you can verify the release (assuming manifest-v0.9.2-alpha.sig and manifest-v0.9.2-alpha.txt are in the current directory) with:
gpg --verify manifest-v0.9.2-alpha.sig manifest-v0.9.2-alpha.txt
You should see the following if the verification was successful:
gpg: Signature made Mon May 1 09:14:42 2023 SAST
gpg: using RSA key 26984CB69EB8C4A26196F7A4D7D916376026F177
gpg: Good signature from "Elle Mouton <elle.mouton@gmail.com>" [ultimate]
That will verify the signature on the main manifest page which ensures integrity and authenticity of the binaries you've downloaded locally. Next, depending on your operating system you should then re-calculate the sha256 sum of the binary, and compare that with the following hashes:
cat manifest-v0.9.2-alpha.txt
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.9.2-alpha
Verifying the Release Timestamp
We have also started to timestamp the manifest file with OpenTimeStamps along with its signature. A new file is now included along with the rest of our release artifacts: manifest-v0.9.2-alpha.sig.ots.
Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following command:
ots verify manifest-v0.9.2-alpha.sig.ots
These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.
Changelog (auto-generated)
What's Changed
- doc: add note for remote lnd credentials by @GeorgeTsagk in #535
- build: update to lnd v0.16.2 by @Roasbeef in #536
New Contributors
- @GeorgeTsagk made their first contribution in #535
Full Changelog: v0.9.1-alpha...v0.9.2-alpha