Lightning Terminal v0.13.1-alpha

This release of Lightning Terminal (LiT) includes updates the integrated LND to the latest release, v0.18.1-beta,
which contains a hot fix.

We'll be continuously working to improve the user experience based on feedback from the community.

Installation and configuration instructions can be found in the README.

This release packages LND v0.18.1-beta, Taproot Assets Daemon v0.3.3-alpha, Loop v0.28.5-beta, Pool v0.6.5-beta and Faraday v0.2.13-alpha.

• IMPORTANT NOTE: To avoid loss of funds, it's imperative that you read the Operational Safety Guidelines before before using tapd on mainnet!

• The Taproot Assets daemon is still in alpha state, which means there can still be bugs and not all desired data safety and backup mechanisms have been implemented yet. Releasing on mainnet mainly signals that there will be no breaking changes in the future and that assets minted with v0.3.0+ will be compatible with later versions.

Important note for Umbrel/Lightning Terminal users

DO NOT UNDER ANY CIRCUMSTANCE uninstall (or re-install) the "Lightning Terminal" app without first making a manual backup of all local tapd data, if you are using Taproot Assets as part of the "Lightning Terminal" app with Umbrel -- or any comparable node-in-a-box solution. Uninstalling Umbrel apps deletes application data. This Taproot Assets application data encumbers Taproot Assets AND bitcoin funds. Receiving and sending tapd assets updates the daemon's funds-custody material. Merely having the lnd seed phrase is NOT enough to restore assets minted or received. WITHOUT BACKUP BEFORE DELETION, FUNDS ARE DESTROYED.

lnd in remote mode (lnd-mode=remote)

NOTE that the minimum version of lnd that can be used in --lnd-mode=remote is v0.17.0-beta.

Required changes when running in lnd remote mode

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 ViktorTigerstrom's key from the ubuntu key server:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 187F6ADD93AE3B0CF335AA6AB984570980684DCC

Once you have his PGP key you can verify the release (assuming manifest-v0.13.1-alpha.sig and manifest-v0.13.1-alpha.txt are in the current directory) with:

gpg --verify manifest-v0.13.1-alpha.sig manifest-v0.13.1-alpha.txt

You should see the following if the verification was successful:

gpg: Signature made Fri Jun 28 23:39:58 2024 CEST
gpg:                using EDDSA key 187F6ADD93AE3B0CF335AA6AB984570980684DCC
gpg: Good signature from "Viktor Tigerström <[email protected]>"

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.13.1-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.13.1-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.13.1-alpha.sig.ots.

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

ots verify manifest-v0.13.1-alpha.sig.ots

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

Release Notes:

https://github.com/lightninglabs/lightning-terminal/blob/master/docs/release-notes/release-notes-0.13.1.md

Lightning Terminal v0.13.0-alpha

Release Notes

This release of Lightning Terminal (LiT) includes an update to the integrated LND version to latest major release of LND: v0.18.0-beta. It also includes updates to the integrated versions of Loop and Pool.

We'll be continuously working to improve the user experience based on feedback from the community.

Installation and configuration instructions can be found in the README.

This release packages LND v0.18.0-beta, Taproot Assets Daemon v0.3.3-alpha, Loop v0.28.5-beta, Pool v0.6.5-beta and Faraday v0.2.13-alpha.

• IMPORTANT NOTE: To avoid loss of funds, it's imperative that you read the Operational Safety Guidelines before before using tapd on mainnet!

• The Taproot Assets daemon is still in alpha state, which means there can still be bugs and not all desired data safety and backup mechanisms have been implemented yet. Releasing on mainnet mainly signals that there will be no breaking changes in the future and that assets minted with v0.3.0+ will be compatible with later versions.

Important note for Umbrel/Lightning Terminal users

DO NOT UNDER ANY CIRCUMSTANCE uninstall (or re-install) the "Lightning Terminal" app without first making a manual backup of all local tapd data, if you are using Taproot Assets as part of the "Lightning Terminal" app with Umbrel -- or any comparable node-in-a-box solution. Uninstalling Umbrel apps deletes application data. This Taproot Assets application data encumbers Taproot Assets AND bitcoin funds. Receiving and sending tapd assets updates the daemon's funds-custody material. Merely having the lnd seed phrase is NOT enough to restore assets minted or received. WITHOUT BACKUP BEFORE DELETION, FUNDS ARE DESTROYED.

lnd in remote mode (lnd-mode=remote)

NOTE that the minimum version of lnd that can be used in --lnd-mode=remote is v0.17.0-beta.

Required changes when running in lnd remote mode

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 her PGP key you can verify the release (assuming manifest-v0.13.0-alpha.sig and manifest-v0.13.0-alpha.txt are in the current directory) with:

gpg --verify manifest-v0.13.0-alpha.sig manifest-v0.13.0-alpha.txt

You should see the following if the verification was successful:

gpg: Signature made Thu Jun  6 15:36:23 2024 EDT
gpg:                using RSA key 26984CB69EB8C4A26196F7A4D7D916376026F177
gpg: Good signature from "Elle Mouton <[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:

cat manifest-v0.13.0-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.13.0-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.13.0-alpha.sig.ots.

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

ots verify manifest-v0.13.0-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

• firewall: session-dependent privacy flags by @bitromortac in #746
• build(deps): bump ejs from 3.1.8 to 3.1.10 in /app by @dependabot in #754
• build(deps): bump github.com/btcsuite/btcd from 0.23.4 to 0.24.0 in /tools by @dependabot in #756
• firewalldb: fetch correct bucket for session level temp KV store by @ellemouton in #763
• accounts: address pendingPayments issues & add tracer by @ellemouton in #766
• Bump litd to version v0.13.0-alpha by @ViktorTigerstrom in #764

Full Changelog: v0.12.5-alpha...v0.13.0-alpha

v0.12.5-alpha

Release Notes

This release of Lightning Terminal (LiT) includes updates to the versions of the integrated LND and Loop daemons.

We'll be continuously working to improve the user experience based on feedback from the community.

Installation and configuration instructions can be found in the README.

This release packages LND v0.17.5-beta, Taproot Assets Daemon v0.3.3-alpha, Loop v0.28.1-beta, Pool v0.6.4-beta and Faraday v0.2.13-alpha.

• IMPORTANT NOTE: To avoid loss of funds, it's imperative that you read the Operational Safety Guidelines before before using tapd on mainnet!

• The Taproot Assets daemon is still in alpha state, which means there can still be bugs and not all desired data safety and backup mechanisms have been implemented yet. Releasing on mainnet mainly signals that there will be no breaking changes in the future and that assets minted with v0.3.0+ will be compatible with later versions.

Important note for Umbrel/Lightning Terminal users

DO NOT UNDER ANY CIRCUMSTANCE uninstall (or re-install) the "Lightning Terminal" app without first making a manual backup of all local tapd data, if you are using Taproot Assets as part of the "Lightning Terminal" app with Umbrel -- or any comparable node-in-a-box solution. Uninstalling Umbrel apps deletes application data. This Taproot Assets application data encumbers Taproot Assets AND bitcoin funds. Receiving and sending tapd assets updates the daemon's funds-custody material. Merely having the lnd seed phrase is NOT enough to restore assets minted or received. WITHOUT BACKUP BEFORE DELETION, FUNDS ARE DESTROYED.

lnd in remote mode (lnd-mode=remote)

NOTE that the minimum version of lnd that can be used in --lnd-mode=remote is v0.17.0-beta.

Required changes when running in lnd remote mode

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 ViktorTigerstrom's key from the ubuntu key server:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 187F6ADD93AE3B0CF335AA6AB984570980684DCC

Once you have his PGP key you can verify the release (assuming manifest-v0.12.5-alpha.sig and manifest-v0.12.5-alpha.txt are in the current directory) with:

gpg --verify manifest-v0.12.5-alpha.sig manifest-v0.12.5-alpha.txt

You should see the following if the verification was successful:

gpg: Signature made Mon Apr 29 11:38:15 2024 CEST
gpg:                using EDDSA key 187F6ADD93AE3B0CF335AA6AB984570980684DCC
gpg: Good signature from "Viktor Tigerström <[email protected]>"

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.12.5-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.12.5-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.12.5-alpha.sig.ots.

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

ots verify manifest-v0.12.5-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

• build(deps): bump github.com/jackc/pgx/v4 from 4.18.1 to 4.18.2 by @dependabot in #730
• build(deps): bump google.golang.org/protobuf from 1.28.0 to 1.33.0 in /tools by @dependabot in #731
• build(deps): bump google.golang.org/protobuf from 1.30.0 to 1.33.0 in /autopilotserverrpc by @dependabot in #732
• build(deps): bump follow-redirects from 1.15.4 to 1.15.6 in /app by @dependabot in #733
• build(deps): bump github.com/docker/docker from 24.0.7+incompatible to 24.0.9+incompatible by @dependabot in #734
• build(deps): bump webpack-dev-middleware from 5.3.1 to 5.3.4 in /app by @dependabot in #735
• build(deps): bump express from 4.17.3 to 4.19.2 in /app by @dependabot in #739
• build(deps): bump tar from 6.2.0 to 6.2.1 in /app by @dependabot in #742
• build(deps): bump webpack from 5.71.0 to 5.89.0 in /app by @dependabot in #745
• build(deps): bump semver from 7.0.0 to 7.6.0 in /app by @dependabot in #744
• build(deps): bump golang.org/x/net from 0.21.0 to 0.23.0 by @dependabot in #748
• build(deps): bump golang.org/x/net from 0.17.0 to 0.23.0 in /autopilotserverrpc by @dependabot in #747
• Bump litd to version v0.12.5-alpha by @ViktorTigerstrom in #750

Full Changelog: v0.12.4-alpha...v0.12.5-alpha

Lightning Terminal v0.12.4-alpha

Release Notes

This release of Lightning Terminal (LiT) includes updates to the versions of the integrated Loop and Faraday daemons.

We'll be continuously working to improve the user experience based on feedback from the community.

Installation and configuration instructions can be found in the README.

This release packages LND v0.17.4-beta, Taproot Assets Daemon v0.3.3-alpha, Loop v0.28.0-beta, Pool v0.6.4-beta and Faraday v0.2.13-alpha.

• IMPORTANT NOTE: To avoid loss of funds, it's imperative that you read the Operational Safety Guidelines before before using tapd on mainnet!

• The Taproot Assets daemon is still in alpha state, which means there can still be bugs and not all desired data safety and backup mechanisms have been implemented yet. Releasing on mainnet mainly signals that there will be no breaking changes in the future and that assets minted with v0.3.0+ will be compatible with later versions.

Important note for Umbrel/Lightning Terminal users

DO NOT UNDER ANY CIRCUMSTANCE uninstall (or re-install) the "Lightning Terminal" app without first making a manual backup of all local tapd data, if you are using Taproot Assets as part of the "Lightning Terminal" app with Umbrel -- or any comparable node-in-a-box solution. Uninstalling Umbrel apps deletes application data. This Taproot Assets application data encumbers Taproot Assets AND bitcoin funds. Receiving and sending tapd assets updates the daemon's funds-custody material. Merely having the lnd seed phrase is NOT enough to restore assets minted or received. WITHOUT BACKUP BEFORE DELETION, FUNDS ARE DESTROYED.

lnd in remote mode (lnd-mode=remote)

NOTE that the minimum version of lnd that can be used in --lnd-mode=remote is v0.17.0-beta.

Required changes when running in lnd remote mode

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 ViktorTigerstrom's key from the ubuntu key server:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 187F6ADD93AE3B0CF335AA6AB984570980684DCC

Once you have his PGP key you can verify the release (assuming manifest-v0.12.4-alpha.sig and manifest-v0.12.4-alpha.txt are in the current directory) with:

gpg --verify manifest-v0.12.4-alpha.sig manifest-v0.12.4-alpha.txt

You should see the following if the verification was successful:

gpg: Signature made Mon Mar 11 13:42:28 2024 CET
gpg:                using EDDSA key 187F6ADD93AE3B0CF335AA6AB984570980684DCC
gpg: Good signature from "Viktor Tigerström <[email protected]>"

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.12.4-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.12.4-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.12.4-alpha.sig.ots.

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

ots verify manifest-v0.12.4-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

• autopilot: generic rules per feature by @bitromortac in #634
• build(deps): bump ip from 1.1.5 to 1.1.9 in /app by @dependabot in #723
• Bump litd to version v0.12.4-alpha by @ViktorTigerstrom in #728

Full Changelog: v0.12.3-alpha...v0.12.4-alpha

Lightning Terminal v0.12.3-alpha

Release Notes

This release of Lightning Terminal (LiT) includes updates to the versions of the integrated LND, Loop and Taproot Assets daemons. This release also includes updates to the Lightning Node Connect implementation, to make connections more robust and more optimised. Furthermore, an issue when starting up LiT has been fixed with this release.

We'll be continuously working to improve the user experience based on feedback from the community.

Installation and configuration instructions can be found in the README.

This release packages LND v0.17.4-beta, Taproot Assets Daemon v0.3.3-alpha, Loop v0.27.0-beta, Pool v0.6.4-beta and Faraday v0.2.11-alpha.

• IMPORTANT NOTE: To avoid loss of funds, it's imperative that you read the Operational Safety Guidelines before before using tapd on mainnet!

• The Taproot Assets daemon is still in alpha state, which means there can still be bugs and not all desired data safety and backup mechanisms have been implemented yet. Releasing on mainnet mainly signals that there will be no breaking changes in the future and that assets minted with v0.3.0+ will be compatible with later versions.

Important note for Umbrel/Lightning Terminal users

DO NOT UNDER ANY CIRCUMSTANCE uninstall (or re-install) the "Lightning Terminal" app without first making a manual backup of all local tapd data, if you are using Taproot Assets as part of the "Lightning Terminal" app with Umbrel -- or any comparable node-in-a-box solution. Uninstalling Umbrel apps deletes application data. This Taproot Assets application data encumbers Taproot Assets AND bitcoin funds. Receiving and sending tapd assets updates the daemon's funds-custody material. Merely having the lnd seed phrase is NOT enough to restore assets minted or received. WITHOUT BACKUP BEFORE DELETION, FUNDS ARE DESTROYED.

lnd in remote mode (lnd-mode=remote)

NOTE that the minimum version of lnd that can be used in --lnd-mode=remote is v0.16.0-beta.

Required changes when running in lnd remote mode

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 ViktorTigerstrom's key from the ubuntu key server:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 187F6ADD93AE3B0CF335AA6AB984570980684DCC

Once you have his PGP key you can verify the release (assuming manifest-v0.12.3-alpha.sig and manifest-v0.12.3-alpha.txt are in the current directory) with:

gpg --verify manifest-v0.12.3-alpha.sig manifest-v0.12.3-alpha.txt

You should see the following if the verification was successful:

gpg: Signature made Thu Feb  8 20:37:05 2024 CET
gpg:                using EDDSA key 187F6ADD93AE3B0CF335AA6AB984570980684DCC
gpg: Good signature from "Viktor Tigerström <[email protected]>"

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.12.3-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.12.3-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.12.3-alpha.sig.ots.

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

ots verify manifest-v0.12.3-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

• fix: add new v2 methods to custom permissions by @secondl1ght in #695
• build(deps): bump golang.org/x/crypto from 0.5.0 to 0.17.0 in /tools by @dependabot in #698
• linter: re-enable the linter by @guggero in #699
• multi: restart LND Client on setup failure by @ViktorTigerstrom in #694
• build(deps): bump follow-redirects from 1.14.9 to 1.15.4 in /app by @dependabot in #703
• status: apply functional options on subServer init by @ViktorTigerstrom in #705
• accounts + main: Allow new accounts with 0 balance by @ViktorTigerstrom in #718
• build(deps): bump github.com/opencontainers/runc from 1.1.5 to 1.1.12 by @dependabot in #717
• Bump litd to version v0.12.3-alpha by @ViktorTigerstrom in #719

Full Changelog: v0.12.2-alpha...v0.12.3-alpha

Lightning Terminal v0.12.2-alpha

Release Notes

This release of Lightning Terminal (LiT) includes updates to the versions of the integrated LND, Loop and Taproot Assets daemons.

We'll be continuously working to improve the user experience based on feedback from the community.

Installation and configuration instructions can be found in the README.

This release packages LND v0.17.3-beta, Taproot Assets Daemon v0.3.2-alpha, Loop v0.26.6-beta, Pool v0.6.4-beta and Faraday v0.2.11-alpha.

• IMPORTANT NOTE: To avoid loss of funds, it's imperative that you read the Operational Safety Guidelines before before using tapd on mainnet!

• The Taproot Assets daemon is still in alpha state, which means there can still be bugs and not all desired data safety and backup mechanisms have been implemented yet. Releasing on mainnet mainly signals that there will be no breaking changes in the future and that assets minted with v0.3.0+ will be compatible with later versions.

Important note for Umbrel/Lightning Terminal users

DO NOT UNDER ANY CIRCUMSTANCE uninstall (or re-install) the "Lightning Terminal" app without first making a manual backup of all local tapd data, if you are using Taproot Assets as part of the "Lightning Terminal" app with Umbrel -- or any comparable node-in-a-box solution. Uninstalling Umbrel apps deletes application data. This Taproot Assets application data encumbers Taproot Assets AND bitcoin funds. Receiving and sending tapd assets updates the daemon's funds-custody material. Merely having the lnd seed phrase is NOT enough to restore assets minted or received. WITHOUT BACKUP BEFORE DELETION, FUNDS ARE DESTROYED.

lnd in remote mode (lnd-mode=remote)

NOTE that the minimum version of lnd that can be used in --lnd-mode=remote is v0.16.0-beta.

Required changes when running in lnd remote mode

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 ViktorTigerstrom's key from the ubuntu key server:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 187F6ADD93AE3B0CF335AA6AB984570980684DCC

Once you have his PGP key you can verify the release (assuming manifest-v0.12.2-alpha.sig and manifest-v0.12.2-alpha.txt are in the current directory) with:

gpg --verify manifest-v0.12.2-alpha.sig manifest-v0.12.2-alpha.txt

You should see the following if the verification was successful:

gpg: Signature made Thu Nov 16 19:26:20 2023 CET
gpg:                using EDDSA key 187F6ADD93AE3B0CF335AA6AB984570980684DCC
gpg: Good signature from "Viktor Tigerström <[email protected]>"

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.12.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.12.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.12.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.12.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

• feat: add keysend messenger to custom permissions by @secondl1ght in #684
• itests: add session linking test by @ellemouton in #639
• firewall + firewalldb: fix typos by @shuoer86 in #686
• chore: update NPM dependencies by @jamaljsr in #685
• build(deps): bump loader-utils from 2.0.2 to 2.0.4 in /app by @dependabot in #687
• main: make error messages more accurate by @nonfungible-human in #678
• build: bump litd to version v0.12.2-alpha by @ViktorTigerstrom in #691

New Contributors

• @secondl1ght made their first contribution in #684
• @shuoer86 made their first contribution in #686

Full Changelog: v0.12.1-alpha...v0.12.2-alpha

Lightning Terminal v0.12.1-alpha

Release Notes

This release of Lightning Terminal (LiT) includes updates to the versions of the integrated LND, Loop and Taproot Assets daemons. This release also updates the documentation for RPC commands to be more coherent, as well as various minor bug fixes.

We'll be continuously working to improve the user experience based on feedback from the community.

Installation and configuration instructions can be found in the README.

This release packages LND v0.17.1-beta, Taproot Assets Daemon v0.3.1-alpha, Loop v0.26.5-beta, Pool v0.6.4-beta and Faraday v0.2.11-alpha.

• IMPORTANT NOTE: To avoid loss of funds, it's imperative that you read the Operational Safety Guidelines before before using tapd on mainnet!

• The Taproot Assets daemon is still in alpha state, which means there can still be bugs and not all desired data safety and backup mechanisms have been implemented yet. Releasing on mainnet mainly signals that there will be no breaking changes in the future and that assets minted with v0.3.0+ will be compatible with later versions.

Important note for Umbrel/Lightning Terminal users

DO NOT UNDER ANY CIRCUMSTANCE uninstall (or re-install) the "Lightning Terminal" app without first making a manual backup of all local tapd data, if you are using Taproot Assets as part of the "Lightning Terminal" app with Umbrel -- or any comparable node-in-a-box solution. Uninstalling Umbrel apps deletes application data. This Taproot Assets application data encumbers Taproot Assets AND bitcoin funds. Receiving and sending tapd assets updates the daemon's funds-custody material. Merely having the lnd seed phrase is NOT enough to restore assets minted or received. WITHOUT BACKUP BEFORE DELETION, FUNDS ARE DESTROYED.

lnd in remote mode (lnd-mode=remote)

NOTE that the minimum version of lnd that can be used in --lnd-mode=remote is v0.16.0-beta.

Required changes when running in lnd remote mode

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 ViktorTigerstrom's key from the ubuntu key server:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 187F6ADD93AE3B0CF335AA6AB984570980684DCC

Once you have his PGP key you can verify the release (assuming manifest-v0.12.1-alpha.sig and manifest-v0.12.1-alpha.txt are in the current directory) with:

gpg --verify manifest-v0.12.1-alpha.sig manifest-v0.12.1-alpha.txt

You should see the following if the verification was successful:

gpg: Signature made Thu Nov 16 19:26:20 2023 CET
gpg:                using EDDSA key 187F6ADD93AE3B0CF335AA6AB984570980684DCC
gpg: Good signature from "Viktor Tigerström <[email protected]>"

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.12.1-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.12.1-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.12.1-alpha.sig.ots.

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

ots verify manifest-v0.12.1-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

• config: allow taproot-assets-mode to be remote by @jamaljsr in #663
• build(deps): bump google.golang.org/grpc from 1.53.0 to 1.56.3 by @dependabot in #669
• build(deps): bump browserify-sign from 4.2.1 to 4.2.2 in /app by @dependabot in #672
• main: make cmd documentation coherent by @nonfungible-human in #671
• multi: update to go 1.21 by @jamaljsr in #675
• build(deps): bump github.com/docker/docker from 20.10.24+incompatible to 24.0.7+incompatible by @dependabot in #674
• build(deps): bump google.golang.org/grpc from 1.53.0 to 1.56.3 in /autopilotserverrpc by @dependabot in #668
• build(deps): bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc from 0.28.0 to 0.46.0 by @dependabot in #680
• build: update litd to version v0.12.1-alpha by @Roasbeef in #682

New Contributors

• @nonfungible-human made their first contribution in #671

Full Changelog: v0.12.0-alpha...v0.12.1-alpha

Lightning Terminal v0.12.0-alpha

Release Notes

This release of Lightning Terminal (LiT) updates the integrated Taproot Assets daemon to the latest version (v0.3.0-alpha), which adds support for Taproot Assets on the Bitcoin mainnet! This release also includes an update to the latest patch release of the integrated Loop daemon.

IMPORTANT NOTE: To avoid loss of funds, it's imperative that you read the Operational Safety Guidelines before using tapd on mainnet!

The Taproot Assets daemon is still in alpha state, which means there can still be bugs and not all desired data safety and backup mechanisms have been implemented yet. Releasing on mainnet mainly signals that there will be no breaking changes in the future and that assets minted with v0.3.0 will be compatible with later versions.

Important note for Umbrel/Lightning Terminal users

DO NOT UNDER ANY CIRCUMSTANCE uninstall (or re-install) the "Lightning Terminal" app without first making a manual backup of all local tapd data, if you are using Taproot Assets as part of the "Lightning Terminal" app with Umbrel -- or any comparable node-in-a-box solution. Uninstalling Umbrel apps deletes application data. This Taproot Assets application data encumbers Taproot Assets AND bitcoin funds. Receiving and sending tapd assets updates the daemon's funds-custody material. Merely having the lnd seed phrase is NOT enough to restore assets minted or received. WITHOUT BACKUP BEFORE DELETION, FUNDS ARE DESTROYED.

We'll be continuously working to improve the user experience based on feedback from the community.

This release packages LND v0.17.0-beta, Taproot Assets Daemon v0.3.0-alpha, Loop v0.26.4-beta, Pool v0.6.4-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.

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 ViktorTigerstrom's key from the ubuntu key server:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 187F6ADD93AE3B0CF335AA6AB984570980684DCC

Once you have his PGP key you can verify the release (assuming manifest-v0.12.0-alpha.sig and manifest-v0.12.0-alpha.txt are in the current directory) with:

gpg --verify manifest-v0.12.0-alpha.sig manifest-v0.12.0-alpha.txt

You should see the following if the verification was successful:

gpg: Signature made Wed Oct 18 21:00:30 2023 CEST
gpg:                using EDDSA key 187F6ADD93AE3B0CF335AA6AB984570980684DCC
gpg: Good signature from "Viktor Tigerström <[email protected]>"

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.12.0-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.12.0-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.12.0-alpha.sig.ots.

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

ots verify manifest-v0.12.0-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

• accounts: fix service check in UpdateAccounts call by @GeorgeTsagk in #651
• build(deps): bump golang.org/x/net from 0.10.0 to 0.17.0 by @dependabot in #652
• build(deps): bump golang.org/x/net from 0.7.0 to 0.17.0 in /autopilotserverrpc by @dependabot in #653
• build(deps): bump @babel/traverse from 7.17.3 to 7.23.2 in /app by @dependabot in #656
• version+README: update LiT, Taproot assets, Loop & LNC versions by @ViktorTigerstrom in #657

Full Changelog: v0.11.0-alpha...v0.12.0-alpha

Lightning Terminal v0.11.0-alpha

Release Notes

This release of Lightning Terminal (LiT) updates the integrated LND daemon version to the latest v0.17.0-beta release, as well as updates the integrated Loop daemon to the latest patch release.

In this release of LiT, a new Status server was added, which enables users to disable the different integrated sub-servers and the integrated accounts sub-system in LiT through configuration. LiT will now also successfully start even if any of the sub-servers or sub-systems fails to start.

This release of LiT also enables the ability to link a new Autopilot session with an old session, as well as enabling the ability to specify feature configurations for an Autopilot session.

One important change to note for users running LiT through docker, is that due to the new status server feature, the startup process of LiT won’t error and end if a sub-server or sub-system fails to start. So any platforms that rely on docker to automatically restart the LiT container if the startup process ends due to the sub-servers or sub-system not having started yet, will now not restart the container as the start process won't exit.

We'll be continuously working to improve the user experience based on feedback from the community.

This release packages LND v0.17.0-beta, Taproot Assets Daemon v0.2.3-alpha, Loop v0.26.3-beta, Pool v0.6.4-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.

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 ViktorTigerstrom's key from the ubuntu key server:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 187F6ADD93AE3B0CF335AA6AB984570980684DCC

Once you have his PGP key you can verify the release (assuming manifest-v0.11.0-alpha.sig and manifest-v0.11.0-alpha.txt are in the current directory) with:

gpg --verify manifest-v0.11.0-alpha.sig manifest-v0.11.0-alpha.txt

You should see the following if the verification was successful:

gpg: Signature made Tue Oct  3 21:26:36 2023 CEST
gpg:                using EDDSA key 187F6ADD93AE3B0CF335AA6AB984570980684DCC
gpg: Good signature from "Viktor Tigerström <[email protected]>"

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.11.0-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.11.0-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.11.0-alpha.sig.ots.

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

ots verify manifest-v0.11.0-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

• multi: Autopilot session linking by @ellemouton in #621
• rules+session_rpc: use existing privacy mapper for obfuscating rules of linked sessions by @ellemouton in #637
• autopilot: feature configuration by @bitromortac in #629
• accounts: don't error out on payment not initiated by @guggero in #640
• multi: allow LND and subserver whitelisted calls by @ellemouton in #617
• terminal: dont block indefinitely on macaroon channel by @ellemouton in #616
• multi: add a Status server by @ellemouton in #541
• Don't shutdown lit on accounts service critical error, and register to status server by @ViktorTigerstrom in #642
• Front-end integration for disabled subservers by @itsrachelfish in #620
• build(deps): bump debug from 4.1.1 to 4.3.1 in /app by @dependabot in #647
• multi: bump lnd to v0.17.0-beta by @guggero in #645

New Contributors

• @bitromortac made their first contribution in #629

Full Changelog: v0.10.5-alpha...v0.11.0-alpha

Lightning Terminal v0.10.5-alpha

Release Notes

This release of Lightning Terminal (LiT) includes an update to the integrated Loop version along with a small UI update use the correct unit for Loop Out swap deadlines.

We'll be continuously working to improve the user experience based on feedback from the community.

This release packages LND v0.16.4-beta, Taproot Assets Daemon v0.2.3-alpha, Loop v0.26.2-beta, Pool v0.6.4-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.

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.10.5-alpha.sig and manifest-v0.10.5-alpha.txt are in the current directory) with:

gpg --verify manifest-v0.10.5-alpha.sig manifest-v0.10.5-alpha.txt

You should see the following if the verification was successful:

gpg: Signature made Tue Aug  8 18:17:56 2023 SAST
gpg:                using RSA key 26984CB69EB8C4A26196F7A4D7D916376026F177
gpg: Good signature from "Elle Mouton <[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:

cat manifest-v0.10.5-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.10.5-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.10.5-alpha.sig.ots.

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

ots verify manifest-v0.10.5-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)