Lightning Terminal v0.14.0-alpha.rc1

[guggero]

This first Release Candidate of Lightning Terminal (LiT) ships the first non-experimental version of Taproot Asset Channels! Make sure to check out the upgrade instructions below if you ran any of the litd v0.13.9xx-experimental versions.

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.4-beta, Taproot Assets Daemon v0.5.0-alpha.rc1, Loop v0.28.8-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.

Breaking changes

Taproot Asset channels are NOT backward compatible with any previous version of Lightning Terminal (litd v0.13.9xx-experimental). See upgrade instructions below if you opened Asset channels with such an experimental version.

The configuration value (taproot-assets.universe.public-access) and command line flag (--taproot-assets.universe.public-access) now needs a value and is no longer a boolean. The value now controls whether the node's universe database can be accessed over RPC and either read (value r) or written to (value w) or both (value rw).
So existing nodes with the configuration file value taproot-assets.universe.public-access=true need to change the value to taproot-assets.universe.public-access=rw. Users specifying the command line flag --taproot-assets.universe.public-access just need to append a value, for example --taproot-assets.universe.public-access=rw.

⚠️ CRITICAL INSTRUCTIONS ⚠️: Required upgrade path for existing litd installations:

To avoid loss of channel funds: Any litd node which ran Taproot Asset channels using any litd v0.13.9xx-experimental versions MUST FOLLOW all of the following procedures:
litd v0.14.0-alpha enhancements require both channel peers to upgrade to a litd version >= v0.14.0-alpha to continue Lightning Channel functionality.
If one channel peer is running litd version <= v0.13.9xx-experimental channel operations are are NOT forwards compatible with litd v0.14.0-alpha versions.

• All Taproot-Asset Lightning channels created using litd version <=, v0.13.9xx-experimental must be cooperatively closed before upgrading to v0.14.0-alpha.
  • Channel Closure instructions
  • Monitor status of lncli pendingchannels: Ensure pending_htlcs response is empty before progressing
    Example: lncli listchannels | jq '.channels[] | select(.pending_htlcs != [])'
• Avoid force closing the channels. If there are pending/in-flight HTLCs, wait for HTLCs to be resolved.
• Once all channels are fully closed (e.g. lncli pendingchannels is empty), both nodes must be upgraded to the new v0.14.0-alpha version before new channels can be opened. Please coordinate the upgrade with your peer if you're not operating both nodes.
• Daemon installations which exclusively contain Taproot Assets on-chain outputs that are not contained within lightning channels, are not required to follow this upgrade path. Anything mentioned above only relates to assets in channels. Normal on-chain assets are not affected.

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.18.4-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 Oliver Gugger's key from the ubuntu key server:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys F4FC70F07310028424EFC20A8E4256593F177720

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

gpg --verify manifest-guggero-v0.14.0-alpha.rc1.sig manifest-v0.14.0-alpha.rc1.txt

You should see the following if the verification was successful:

gpg: Signature made Wed Nov 27 22:00:28 2024 CET
gpg:                using RSA key F4FC70F07310028424EFC20A8E4256593F177720
gpg: Good signature from "Oliver Gugger <[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.14.0-alpha.rc1.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.14.0-alpha.rc1

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

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

ots verify manifest-guggero-v0.14.0-alpha.rc1.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/update-to-lnd-18-4/docs/release-notes/release-notes-0.14.0.md

---

This discussion was created from the release Lightning Terminal v0.14.0-alpha.rc1.