Releases: lightninglabs/lightning-terminal
Lightning Terminal v0.14.0-alpha
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
, Loop v0.29.0-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:
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.
Oracle RPC:
The RPC protobuf definitions for the Price Oracle have changed. Asset exchange rates are now expressed as FixedPoint
to achieve better precision.
The rationale for the change and the new math behind it are described in the new RFQ document.
Code examples for a Price Oracle server are available here.
Configuration changes:
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
.
litcli
changes:
The Taproot Asset Channel related sub commands of litcli ln
no longer require a custom macaroon to be specified, they now work with the default lit.macaroon
. So in most setups the --macaroonpath
flag no longer needs to be specified, if the litd.macaroon
is located in a default directory.
⚠️ 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 tov0.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 newv0.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.
NOTE: Taproot Assets Channel functionality is only available when both lnd
and tapd
are running in the same process (by setting both
lnd-mode=integrated
and taproot-assets-mode=integrated
). Remote mode support
will be added in the future.
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.sig
and manifest-v0.14.0-alpha.txt
are in the current directory) with:
gpg --verify manifest-guggero-v0.14.0-alpha.sig manifest-v0.14.0-alpha.txt
You should see the following if the verification was successful:
gpg: Signature made Thu Dec 19 2024 22:00:46 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.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
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.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.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:
Lightning Terminal v0.14.0-alpha.rc2
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.rc2
, Taproot Assets Daemon v0.5.0-alpha.rc2
, 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:
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.
Oracle RPC:
The RPC protobuf definitions for the Price Oracle have changed. Asset exchange rates are now expressed as FixedPoint
to achieve better precision.
The rationale for the change and the new math behind it are described in the new RFQ document.
Code examples for a Price Oracle server are available here.
Configuration changes:
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
.
litcli
changes:
The Taproot Asset Channel related sub commands of litcli ln
no longer require a custom macaroon to be specified, they now work with the default lit.macaroon
. So in most setups the --macaroonpath
flag no longer needs to be specified, if the litd.macaroon
is located in a default directory.
⚠️ 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 tov0.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 newv0.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.rc2.sig
and manifest-v0.14.0-alpha.rc2.txt
are in the current directory) with:
gpg --verify manifest-guggero-v0.14.0-alpha.rc2.sig manifest-v0.14.0-alpha.rc2.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.rc2.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.rc2
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.rc2.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.rc2.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:
Lightning Terminal v0.14.0-alpha.rc1
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:
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.
Oracle RPC:
The RPC protobuf definitions for the Price Oracle have changed. Asset exchange rates are now expressed as FixedPoint
to achieve better precision.
The rationale for the change and the new math behind it are described in the new RFQ document.
Code examples for a Price Oracle server are available here.
Configuration changes:
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
.
litcli
changes:
The Taproot Asset Channel related sub commands of litcli ln
no longer require a custom macaroon to be specified, they now work with the default lit.macaroon
. So in most setups the --macaroonpath
flag no longer needs to be specified, if the litd.macaroon
is located in a default directory.
⚠️ 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 tov0.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 newv0.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:
Lightning Terminal v0.13.6-alpha
This release of Lightning Terminal (LiT) includes a hotfix that updates application version of LiT, which was unchanged in v0.13.5-alpha
.
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.3-beta
, Taproot Assets Daemon v0.4.1-alpha
, 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.
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.1-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.6-alpha.sig
and manifest-v0.13.6-alpha.txt
are in the current directory) with:
gpg --verify manifest-v0.13.6-alpha.sig manifest-v0.13.6-alpha.txt
You should see the following if the verification was successful:
gpg: Signature made Mon Oct 28 12:48:02 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.13.6-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.6-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.6-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.6-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:
Lightning Terminal v0.13.5-alpha
This release of Lightning Terminal (LiT) includes updates to the integrated version Loop (v0.28.8-beta). We also introduce changes in this release, which ensures that all future releases will be fully reproducible on all environments.
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.3-beta
, Taproot Assets Daemon v0.4.1-alpha
, 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.
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.1-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.5-alpha.sig
and manifest-v0.13.5-alpha.txt
are in the current directory) with:
gpg --verify manifest-v0.13.5-alpha.sig manifest-v0.13.5-alpha.txt
You should see the following if the verification was successful:
gpg: Signature made Fri Oct 25 20:50:17 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.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.13.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.13.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.13.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.
Release Notes:
Lightning Terminal v0.13.995-experimental
litd v0.13.995-experimental includes the latest tapd
features an bug fixes as well as litd upgrades.
Release Notes
The Lightning Terminal (LiT) experimental release is the alpha-preview build that brings Taproot Assets to the Lightning Network, with support for Taproot Asset Channels.
Please note that Taproot Asset Channel functionality is only supported when litd
runs with both lnd
and tapd
in integrated mode (--lnd-mode=integrated
and --taproot-assets-mode=integrated
).
General installation and configuration instructions can be found in the README.
Key Updates
- Clarify Asset Balance Reporting:
ListBalances
now supports theinclude_leased
flag, which will include leased asset balances in balance queries. - Tap Channel Liquidity Fixes: Fixed issues with tap channel liquidity calculations, including sending very small or very big asset amounts.
- RFQ Price-acceptance Tolerances: Added AcceptPriceDeviationPpm configuration.
- RFQ Quote Accept Message Parsing: Improved RFQ quote accept message parsing by looking up the associated quote request message.
- Aux Signer Signal Handling: Improved aux signer signal handling to prevent quit signals from being missed.
- Coin Select Type: Added a new CoinSelectType enum to FundVirtualPsbt to specify script key type.
- Dust Checks for Allocations: Added dust checks for allocations in tap channels.
Performance and Stability Improvements
- Parallel Proof Delivery
- Error Handling in parallel processing
- Server Logging Cleanup: log calls moved from info to trace and merged log messages.
Important Notes
-
This release packages a staging/testing branch of LND, Taproot Assets Daemon, Loop, Pool, and Faraday.
-
⚠️ **IMPORTANT NOTE: To avoid loss of funds, please 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.
What's Changed
- Updated to latest
tapd
version to v0.13.995. - Fixed bugs related to TAP channel liquidity..
- Added custom channels liquidity edge cases test.
- [custom channels]: plumb payinvoice CLI arg by @jharveyb in #838
New Contributors
- @jharveyb made their first contribution.
Full Changelog: v0.13.994-experimental...v0.13.995-experimental
Lightning Terminal v0.13.4-alpha
This release of Lightning Terminal (LiT) includes updates to the integrated versions of LND (v0.18.3-beta) and Loop (v0.28.7-beta).
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.3-beta
, Taproot Assets Daemon v0.4.1-alpha
, Loop v0.28.7-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.1-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.4-alpha.sig
and manifest-v0.13.4-alpha.txt
are in the current directory) with:
gpg --verify manifest-v0.13.4-alpha.sig manifest-v0.13.4-alpha.txt
You should see the following if the verification was successful:
gpg: Signature made Mon Sep 16 16:59:51 2024 +07
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.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.13.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.13.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.13.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.
Release Notes:
Lightning Terminal v0.13.994-experimental
This version includes the latest bugfixes in tapd
as well as new convenience RPCs for easier interaction with Taproot Asset Channels. See lightninglabs/taproot-assets#1048 for more information on the new tapchannelrpc.AddInvoice
and tapchannelrpc.SendPayment
RPCs.
Release Notes
This release of Lightning Terminal (LiT) is the first, experimental alpha preview build that brings Taproot Assets to the Lightning Network, with support for Taproot Asset Channels.
We'll be continuously working to improve the user experience based on feedback from the community.
Please note that Taproot Asset Channel functionality is only supported when litd
runs with both lnd
and tapd
in integrated mode (--lnd-mode=integrated
and --taproot-assets-mode=integrated
).
General installation and configuration instructions can be found in the README.
Guides for minting assets and setting up Taproot Asset Channels in a test environment can be found here:
This release packages a staging/testing branch of LND v0.18.0-beta
, Taproot Assets Daemon v0.4.1
, 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.
Breaking changes
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
.
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 guggero
's key from the ubuntu key server:
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys F4FC70F07310028424EFC20A8E4256593F177720
Once you have her PGP key you can verify the release (assuming manifest-v0.13.994-experimental.sig
and manifest-v0.13.994-experimental.txt
are in the current directory) with:
gpg --verify manifest-v0.13.994-experimental.sig manifest-v0.13.994-experimental.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 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.13.994-experimental.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.994-experimental
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.994-experimental.sig.ots
.
Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following command:
ots verify manifest-v0.13.994-experimental.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
Full Changelog: v0.13.993-experimental...v0.13.994-experimental
Lightning Terminal v0.13.993-experimental
This version includes the latest bugfixes in tapd
as well as new convenience RPCs for easier interaction with Taproot Asset Channels. See lightninglabs/taproot-assets#1048 for more information on the new tapchannelrpc.AddInvoice
and tapchannelrpc.SendPayment
RPCs.
Release Notes
This release of Lightning Terminal (LiT) is the first, experimental alpha preview build that brings Taproot Assets to the Lightning Network, with support for Taproot Asset Channels.
We'll be continuously working to improve the user experience based on feedback from the community.
Please note that Taproot Asset Channel functionality is only supported when litd
runs with both lnd
and tapd
in integrated mode (--lnd-mode=integrated
and --taproot-assets-mode=integrated
).
General installation and configuration instructions can be found in the README.
Guides for minting assets and setting up Taproot Asset Channels in a test environment can be found here:
This release packages a staging/testing branch of LND v0.18.0-beta
, Taproot Assets Daemon v0.4.1
, 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.
Breaking changes
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
.
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 guggero
's key from the ubuntu key server:
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys F4FC70F07310028424EFC20A8E4256593F177720
Once you have her PGP key you can verify the release (assuming manifest-v0.13.993-experimental.sig
and manifest-v0.13.993-experimental.txt
are in the current directory) with:
gpg --verify manifest-v0.13.993-experimental.sig manifest-v0.13.993-experimental.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 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.13.993-experimental.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.993-experimental
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.993-experimental.sig.ots
.
Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following command:
ots verify manifest-v0.13.993-experimental.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
- litclient: add taprpc packages to
Registrations
by @jamaljsr in #816 - [custom channels]: bump taproot assets dependency, add missing CLI flag by @guggero in #817
- [custom channels]: bump to latest version of tapd, set version to v0.13.993-experimental by @guggero in #819
Full Changelog: v0.13.992-experimental...v0.13.993-experimental
Lightning Terminal v0.13.992-experimental
This version includes the latest bugfixes in tapd
as well as new convenience RPCs for easier interaction with Taproot Asset Channels. See lightninglabs/taproot-assets#1048 for more information on the new tapchannelrpc.AddInvoice
and tapchannelrpc.SendPayment
RPCs .
Release Notes
This release of Lightning Terminal (LiT) is the first, experimental alpha preview build that brings Taproot Assets to the Lightning Network, with support for Taproot Asset Channels.
We'll be continuously working to improve the user experience based on feedback from the community.
Please note that Taproot Asset Channel functionality is only supported when litd
runs with both lnd
and tapd
in integrated mode (--lnd-mode=integrated
and --taproot-assets-mode=integrated
).
General installation and configuration instructions can be found in the README.
Guides for minting assets and setting up Taproot Asset Channels in a test environment can be found here:
This release packages a staging/testing branch of LND v0.18.0-beta
, Taproot Assets Daemon v0.4.1
, 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.
Breaking changes
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
.
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 guggero
's key from the ubuntu key server:
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys F4FC70F07310028424EFC20A8E4256593F177720
Once you have her PGP key you can verify the release (assuming manifest-v0.13.992-experimental.sig
and manifest-v0.13.992-experimental.txt
are in the current directory) with:
gpg --verify manifest-v0.13.992-experimental.sig manifest-v0.13.992-experimental.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 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.13.992-experimental.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.992-experimental
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.992-experimental.sig.ots
.
Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following command:
ots verify manifest-v0.13.992-experimental.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
- [custom channels]: Use new
tapchannelrpc
RPC methods by @guggero in #807 - [custom channels]: bump experimental branch to latest taproot-assets version, increase version to v0.13.992-experimental by @guggero in #815
Full Changelog: v0.13.991-experimental...v0.13.992-experimental