Release Notes

This is the second public release candidate of the first major update of Lightning Terminal (LiT)!

This release packages LND v0.11.1-beta, Loop v0.9.0-beta, and Faraday v0.2.1-alpha.

Installation and configuration instructions can be found in the README.

Changes since RC3

• The default mode is now set to "remote".
• In "remote" mode, LiT now assumes default settings to connect to lnd. That allows LiT to be started with minimal configuration settings or command line flags if the lnd node it should connect to is running on the same host and uses default settings.
• LiT now shows useful information about the lnd node it is connected to on startup as well as the address where the UI can be reached at.

Remote lnd support

This is the main new feature of this release: We now support connecting LiT to an existing lnd node that's either running on a remote or local host.

Users of LiT now have two main modes to run the terminal in: The "integrated lnd" or the "remote lnd" mode. Depending on that decision, the command line flags or configuration options that need to be set are substantially different.

Breaking changes

LiT now always uses its own configuration file, by default located in ~/.lit/lit.conf. If you used a previous version of LiT, please move the adjusted lnd.conf (where you added all the lnd. prefixes) to that file.

Also please take a look at the configuration examples and explanations here.

Testers

Note that this is a pre-release of a branch that is not yet merged into the master branch and hasn't been fully reviewed. The goal of this pre-release is to get feedback on the user friendliness of the new command line flags/config options for the remote mode is appreciated.

Please take a look at the docs and examples linked above and also the full output of litd --help and let us know if you are able to operate LiT in the desired mode with the documentation that is available.

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 guggero's key from keybase:

curl https://keybase.io/guggero/pgp_keys.asc | gpg --import

Once you have his PGP key you can verify the release (assuming manifest-v0.2.0-alpha.rc3.txt.asc is in the current directory) with:

gpg --verify manifest-v0.2.0-alpha.rc34txt.asc

You should see the following if the verification was successful:

gpg: Signature made Mi 29 Jul 2020 14:59:19 CEST
gpg:                using RSA key 6E01EEC9656903B0542B8F1003DB6322267C373B
gpg: Good signature from "Oliver Gugger <gugger@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.2.0-alpha.rc4.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.2.0-alpha.rc4

Verifying the Release Timestamp

From this new version onwards we'll also now 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.2.0-alpha.rc4.txt.asc.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following command:

ots verify manifest-v0.2.0-alpha.rc4.txt.asc.ots

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Contributors (Alphabetical Order)

Jamal James
Oliver Gugger