DeviceInfo: drop .providerId, introduce .providerName

{
    version: "1.4.2",
    isBootloader: false,
    isOSU: false,
    managerAllowed: false,
    mcuVersion: "1.6",
    pinValidated: true,
-   providerId: 1,
+   providerName: null,
    majMin: "1.4",
    targetId: 823132163,
  }

There were a bad design in DeviceInfo type that was still involving a .providerId that dynamically could changes based on getEnv. this information have no sense to be in a hw getDeviceInfo because that's a dynamic value, it's not a immutable/raw info

This commit introduces back the feature via a getProviderId that takes DeviceInfo and gives you that value. We also introduces helpers to implement a "blue" dot on the manager tab

There is no impact on desktop because we don't use .providerId. Even tho there is no impact, This is a major bump of live-common because it's still an important change. we also want to more easily identify the next live version we will do (at this is used in manager header).

import { useManagerBlueDot } from "@ledgerhq/live-common/lib/manager/hooks";

const displayBlueDot = useManagerBlueDot(lastSeenDevice);

• Be resilient to bad currencyId in appstore app data

• parse account utxo as utxo to have the rbf info

• prepare some logic for firmware updates regarding the "allow non-OSU auto flashing OR timeout 20s" incoming idea. (not impacting anything as of today)

• Workaround libcore segfault on BitcoinLikeOutput#isReplaceable

XRP fixes

Fixes XRP pending operation to have a wrong transaction hash displayed also causing the Operation Detail modal to disappear a few second after broadcast.

Bitcoin coin control features

Changes

• transactions are no longer RBF enabled.
• by default, unconfirmed RBF are excluded.
• we have finer coin control.

QA implications

• must carefully test bitcoin and its forks and especially Send flow. This is especially relevant as the total to spend / amount / error validation have changed its logic.
• use coin control feature as a way to test more transaction scenarios but don't test the feature itself, it's a dev only thing for now until we make it stable. (only consider testing what user will see with the checkbox)

Type additions in live-common model

• Account#bitcoinResources.utxos
• TransactionStatus#txInputs
• TransactionStatus#txOutputs
• Transaction#utxoStrategy

CLI options

• transaction commands have a --excludeUTXO, -E that allows to exclude specific utxo (format is hash@index)
• transaction commands have a --rbf that allows to enable rbf
• transaction commands have a --bitcoin-picking-strategy that allows to change the picking strategy
• account formatter will display the utxo list, up to DEBUG_UTXO_DISPLAY items. (set to a low 4 at the moment)
• status formatter will display the inputs / outputs

bot benefit the better formatting

▬ BitcoinCash 1.4.2 on nanoS 1.6.1-rc1
→ FROM Bitcoin Cash 1: BCH 0.009973 (251ops) (15CPMSZxwNCdzsHgktAKhYeo2pbH17vNhM on 44'/145'/0'/0/128) #0 xpub6CbdHiHA7R6VATXLiGDgidcx2VAmrMZnHq7c6eqGVgaDQe5aS2jyW2F7c2vTbiyG6XeS547DGZc7u3wA4jHUamMas4WVtENyxLWv1eSezWA
3 UTXOs
0.00562      1BKdSpCVhNkRkbxLaHDVX6WT4uHfkPH346 9ca70ea4da8fc7c5781b5d5a1648bf86fc5906d255cf97f10ac45dcaf2d3dc9b @0 (10)
0.0028446    1MDXDF2ACyswTxVXqNiGpQeN2AikyQaNZe e5e25edd8331366d314509cad6542cf870bbc709bfc55d3f6a4f806535c0d83c @0 (9)
0.0015083    1AesUoJSgc6N23C6839G477PLLE66odoKW 646476ae10339fa4a87c35177a0b5143860bccfb1d3ccbc48e09eb0262ce2364 @0 (29)
max spendable ~0.009968
★ using mutation 'optimize-size'
→ TO Bitcoin Cash 2: BCH 0.0005062 (241ops) (1VYP2RDwTTLm9M3mDTFgRtfQbuuQnyYrS on 44'/145'/1'/0/113) #1 xpub6CbdHiHA7R6VBbcqmQoKK2CJDZpnfvofQamDeniLhH3Hkrs449jJvBvUpVdLBddUvVtTj2kWSmvdBenFjYo5wwv7poYkEvftBP1R8rdAYSM
✔️ transaction 
SEND BCH 0.00740702
TO 1VYP2RDwTTLm9M3mDTFgRtfQbuuQnyYrS
with feePerByte=1 (network fees: 0=1, 1=1, 2=1)
OPTIMIZE_SIZE
STATUS (4.7s)
TX INPUTS (2):
0.00562      1BKdSpCVhNkRkbxLaHDVX6WT4uHfkPH346 9ca70ea4da8fc7c5781b5d5a1648bf86fc5906d255cf97f10ac45dcaf2d3dc9b@0
0.0028446    1MDXDF2ACyswTxVXqNiGpQeN2AikyQaNZe e5e25edd8331366d314509cad6542cf870bbc709bfc55d3f6a4f806535c0d83c@0
TX OUTPUTS (2):
0.007407     1VYP2RDwTTLm9M3mDTFgRtfQbuuQnyYrS rbf @0 (0)
0.0010539    1HiJPYVSmJqVq8eEFsoxnf1vxP29XwbSGm 44'/145'/0'/1/61 rbf @1 (0)
  amount: BCH 0.00740702
  estimated fees: BCH 0.00000374
  total spent: BCH 0.00741076
✔️ has been signed! (12.8s) 
✔️ broadcasted! (2844ms) optimistic operation: 
  - BCH 0.00741076   OUT        3cbb64a0f93a501dc479673594ce5eb04f7c9f682451d3475cb81219f736711f 2020-06-28T15:41
✔️ operation confirmed (38.4s): 
  - BCH 0.00741076   OUT        3cbb64a0f93a501dc479673594ce5eb04f7c9f682451d3475cb81219f736711f 2020-06-28T15:42
✔️ Bitcoin Cash 1: BCH 0.0025622 (252ops) (15CPMSZxwNCdzsHgktAKhYeo2pbH17vNhM on 44'/145'/0'/0/128) #0 xpub6CbdHiHA7R6VATXLiGDgidcx2VAmrMZnHq7c6eqGVgaDQe5aS2jyW2F7c2vTbiyG6XeS547DGZc7u3wA4jHUamMas4WVtENyxLWv1eSezWA
2 UTXOs
0.0015083    1AesUoJSgc6N23C6839G477PLLE66odoKW 646476ae10339fa4a87c35177a0b5143860bccfb1d3ccbc48e09eb0262ce2364 @0 (29)
0.0010539    1HiJPYVSmJqVq8eEFsoxnf1vxP29XwbSGm 3cbb64a0f93a501dc479673594ce5eb04f7c9f682451d3475cb81219f736711f @1 (0)
(final state reached in 38.3s)

• firmware update: wait ~20s that osu is ready before final firmware update
• lib/account: isAccountBalanceUnconfirmed

Ethereum

• Implement getDryRunGasLimit that will improve the gas limit calculation
• api/Ethereum to parse everything as bignumber

• missing device wordings

• add 'Bootloader mode' device wording
• add family specific account & operation formatters
• improve device app logic to warn for outdated apps

• add logic for firmware update and update error code for next firmwares
• LL-2589 (deviceWording): restoreConfiguration wording updated
• Cosmos: Fix calculate fees when all amount is at 0

cosmos development

• Fees and gas fix
• disable rounding

cosmos development

• Change broadcast mode from block to sync
• clean fee when mode change or number of validators change
• disable cosmos blockAvgTime to disable confirmation mechanism
• Fix fees on send flow

• LL-2774 fix pending operation ordering

Cosmos development

• Fix Fees + remove gas
• fix address text to address
• change from staging to prod url

Cosmos development

• precalc fees in prepare transaction to fix issues with fees changing at device step

CLI

• firmwareUpdate command to use device param

cosmos development

• fix network call
• Fetch sequenceNumber from explorer always
• trigger notEnoughBalance error when useAllAmount used with a balance of zero

stellar

• Add memo field

Cosmos development

• filter delegation that has a 0 amount
• Add memo in extra field
• Memo
• fix delegation list issue + prepare for send max with ongoing delegations

tezos

fixes tezos bakers v2 issue

Features

• Firmware updates: Apps will be uninstalled and reinstalled automatically
• New indicator to inform the balance is not yet confirmed when an operation is still pending confirmation
• New warning that displays each time you use an outdated app
• Indication when a device has an outdated firmware

Bug fixes

• Ethereum: Better gasLimit estimation to fix “out of gas” issues
• Fix on XRP pending operation to have a wrong transaction hash displayed
• Fix on Ethereum Classic balance and amount precision issue
• Fix on Linux icon

RBF transactions

• Fix a bug creating wrong balance for cancelled RBF transactions
• Fix on the Send flow to not use RBF transaction output when they are not confirmed
• RBF to be disabled by default for a regular Send

Other

• Wording rework

• hw-app-trx: unsafe sign transaction by hash (#499)
• hw-app-btc: add back the method serializeTransactionOutputs as part of btc instance (also available as a raw function)

• hw-app-eth: Update erc20 list (including COMP and some others)
• hw-app-eth: Fix EIP 155 chunking (#514)

Bug fixes

• Do not include the Onion-Location header for custom domains mapping (@NicolasDorier)
• Fix warning message when using SQLite (@NicolasDorier)
• Create store could be called with a scoped store's modify apikey (@NicolasDorier)
• Crowdfunding app used with a custom domain were showing blank page (@NicolasDorier)

Bug fixes

• Point of sales app used with a custom domain were showing blank page (@NicolasDorier)

New Feature and improvements

• Add Notifications feature (@r0ckstardev)
• Add Pull Payments feature (@NicolasDorier)
• Add Refund feature (@NicolasDorier
• Allow invoice and payment requests to be archived (hide from list) (@Kukks)
• Improve fee selection UI in wallet send screen (@Kukks)
• Show warning when enabling Payjoin but supported payment methods are not using a hot wallet (@Kukks)
• Rebuild POS and Crowdfund App Item/Perk editor UI and fix any issues (@Kukks)
• Adjust Payjoin to the new specification outlined in BIP78 (@NicolasDorier)
• Allow opening the BTCPay wallet natively when clicking a Bitcoin payment link (BIP21)
• Add Server Info GreenField API (@dennisreimann)
• Add Payment Requests GreenField API (@Kukks @NicolasDorier)
• Support specifying payment method through apps per item/perk (@Kukks)
• Allow setting private route hints for LND invoices (@r0ckstardev)
• Expand GreenField Store API to have more store properties (@Kukks @NicolasDorier)
• Make GreenField local docs require authentication (@Kukks)
• Privacy enhancement: Randomize wallet transaction fingerprint. (@NicolasDorier)
• Randomize RBF support in BTCPay wallet by default for privacy (@NicolasDorier)
• Add support for Cobo Vault wallet file import (@Kukks)
• Add support for Wasabi wallet file import (@Kukks)
• Split POS app cart and static and support both simultaneously (@dennisreimann)
• Add Cross-Implementation Lightning Node GreenField API (@Kukks @NicolasDorier)
• Make GreenField responses and JSON properties consistent (@Kukks @NicolasDorier)
• Add Tor Onion-Location HTTP header (@dennisreimann)
• Rename form items in Wallet Send UI (@pavlenex)
• Add ThunderHub integration (@NicolasDorier)

• Add option to attempt to create PSBT with full transaction for inputs to sign for Trezor (@Kukks)

  Bug fixes

• Do not auto-complete generate wallet form (@Kukks)

• Make sure copied notification is positioned correctly on checkout (@chewsta)

• Fix broken documentation links (@Kukks @dennisreimann @jad0c @Eskyee @pavlenex)

• Fix POS app item display issues (@bolatovumar)

• Fix Invoice checkout modal close button theme issues (@bolatovumar)

• Fix display of replaced transactions in invoice list (@NicolasDorier)

• Support BitPay invoice creation property "paymentCurrencies" (@Kukks)

• Update lightning support warning text (@janoside)

• Fix issue with payment requests not expiring (@Kukks)

• Fix broken Bootstrap theme generator link (@Kukks)

• Use proper Bitcoin symbol (₿) in UI instead of "BTC" (@Kukks)

• Ensure you can only sign with hot wallet if you created the hot wallet via seed (@NicolasDorier)

• Respect JsonResponse option in payment button endpoint even for failures (@Kukks)

• Opt out of dotnet telemetry in Docker containers (@Kukks)

• Fix issue with POS app if button text had special formatting (@Kukks)

• Autofocus 2FA-code input on page load (@dennisreimann)

• Add Orderid to BitPay IPN format (@Kukks)

• Require Owner role to the store for modifying store via Greenfield (@NicolasDorier)

• Fix css styling classes (@woutersamaey)

• Fix checkout high width resolution styling issues (@dennisreimann)

• Fix zpub electrum import (@gruve-p)

This is the 3rd minor release in the v0.10.0-beta-series. Unlike v0.10.2-beta which only includes bug-fixes, this release also includes some refactoring to the main lnd package that allows lnd to more easily be embedded as a normal struct (by importing the package) on other Go projects.

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 the keys that have signed this release if you haven't done so already:

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

Once you have the required PGP keys, you can verify the release (assuming manifest-v0.10.3-beta.rc1.txt and manifest-v0.10.3-beta.rc1.txt.sig are in the current directory) with:

gpg --verify manifest-v0.10.3-beta.rc1.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.10.3-beta.rc1.txt'
gpg: Signature made Mon Jun 29 17:11:22 2020 PDT
gpg:                using RSA key 4AB7F8DA6FAEBB3B70B1F903BC13F65E2DC84465
gpg: Good signature from &#34;Olaoluwa Osuntokun <laolu32@gmail.com>&#34; [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.13.12, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<os-arch> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

git verify-tag v0.10.3-beta.rc1

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.10.3-beta.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.10.3-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.10.3-beta" ./cmd/lnd
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.10.3-beta" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

lnd Package Refactoring

In prior releases, we've started to refactor the way lnd is initialized and started to make it easier to emebdd lnd in other Go applications. The primary consumer of these APIs so far has been our mobile bindings for lnd. In this release we continue the process to further abstract the lnd package with a series of PRs that remove a number of global variables, allow external sub-server registration, and external logging hooks.

The full list of changes since v0.10.2-beta can be found here:

• https://github.com/lightningnetwork/lnd/compare/v0.10.2-beta-rc4-branch...v0.10.3-beta-rc1-branch

Contributors (Alphabetical Order)

Oliver Gugger /laolu32@gmail.com

This marks the second minor release in the v0.10.0 series! This release allows lnd to be compatible with bitcoind 0.20, resolves some peer connection instability issues, fixes an issue that can cause payments to hang ina state until a connection is cycled, and fixes an important bug related to an on disk Static Channel Backups (SCB).

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 the keys that have signed this release if you haven't done so already:

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

Once you have the required PGP keys, you can verify the release (assuming manifest-v0.10.2-beta.rc4.txt and manifest-v0.10.2-beta.rc4.txt.sig are in the current directory) with:

gpg --verify manifest-v0.10.2-beta.rc4.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.10.2-beta.rc4.txt'
gpg: Signature made Thu Jun 18 17:50:06 2020 PDT
gpg:                using RSA key 4AB7F8DA6FAEBB3B70B1F903BC13F65E2DC84465
gpg: Good signature from &#34;Olaoluwa Osuntokun <laolu32@gmail.com>&#34; [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.13.12, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<os-arch> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

git verify-tag v0.10.2-beta.rc4

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.10.2-beta.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.10.2-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.10.2-beta" ./cmd/lnd
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.10.2-beta" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

Network Gossip Channel Announcement Feature Bit Encoding

This release fixes an existing bug that would cause us to not carry over the ChannelUpdate level feature bits when sending a channel announcement suit to a connected node. Some nodes have started to use this space to communicate that they support "wumbo" channels. Before this change, if lnd was instructed to send the channel announcement for a wumbo channel, it would omit this feature bit information, causing the requesting node to reject the announcement as the signature would fail. This may have cause some peer connection instability since these wumbo channels have started to be more widely propagated across the network.

Synchronous Switch <-> Link HTLC Handoff

This release modifies the way a new payment is sent to the first outgoing channel it needs to traverse before being sent off to the network. Before this commit, the router would hand the payment off to the switch in an asynchronous manner. Recently, it was brought to our attention that this behavior could at times cause a payment to unnecessarily fail later if the target link wasn't online, or not fully available. In this new release, this process is now synchronous. End users should observe that they see less internal payment failures due to out of date bandwidth hints, as is now able to full see through the addition of a new HTLC.

bitcoind Compatibility

With this new release, lnd can now be used with bitcoind 0.20 as it's full-node chain backend.

SCB Bug Fix

This release includes an important bug fix for static channel backups. Before this release, if a new lnd node was started with a data directory that contained an existing SCB file, then that existing file would be completely overridden by whatever channel state the new lnd node started with.

With this new release, of lnd, we'll fail to start if we're unable to read an existing SCB file on disk. Additionally, we'll always combine the contents of the SCB file with our in-memory channel state.

The full list of changes since v0.10.1-beta can be found here:

• https://github.com/lightningnetwork/lnd/compare/v0.10.1-beta...v0.10.2-beta-rc4-branch

Contributors (Alphabetical Order)

Andras Banki-Horvath Olaoluwa Osuntokun Oliver Gugger Joost Jager Wilmer Paulino /laolu32@gmail.com

This marks the second minor release in the v0.10.0 series! This release allows lnd to be compatible with bitcoind 0.20, and fixes an important bug related to an on disk Static Channel Backups (SCB).

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 the keys that have signed this release if you haven't done so already:

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

Once you have the required PGP keys, you can verify the release (assuming manifest-v0.10.2-beta.rc2.txt and manifest-v0.10.2-beta.rc2.txt.sig are in the current directory) with:

gpg --verify manifest-v0.10.2-beta.rc2.txt.sig

You should see the following if the verification was successful:

gpg: assuming signed data in 'manifest-v0.10.2-beta.rc2.txt'
gpg: Signature made Thu Jun 18 17:50:06 2020 PDT
gpg:                using RSA key 4AB7F8DA6FAEBB3B70B1F903BC13F65E2DC84465
gpg: Good signature from &#34;Olaoluwa Osuntokun <laolu32@gmail.com>&#34; [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.13.10, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, routerrpc, and watchtowerrpc. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<os-arch> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

git verify-tag v0.10.2-beta.rc2

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming that vendor.tar.gz and lnd-source-v0.10.2-beta.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz
tar -xvzf lnd-source-v0.10.2-beta.tar.gz
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.10.2-beta" ./cmd/lnd
GO111MODULE=on go install -v -mod=vendor -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.10.2-beta" ./cmd/lncli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

bitcoind Compatibility

With this new release, lnd can now be used with bitcoind 0.20 as it's full-node chain backend.

SCB Bug Fix

This release includes an important bug fix for static channel backups. Before this release, if a new lnd node was started with a data directory that contained an existing SCB file, then that existing file would be completely overridden by whatever channel state the new lnd node started with.

With this new release, of lnd, we'll fail to start if we're unable to read an existing SCB file on disk. Additionally, we'll always combine the contents of the SCB file with our in-memory channel state.

The full list of changes since v0.10.1-beta can be found here:

• https://github.com/lightningnetwork/lnd/compare/v0.10.1-beta...v0.10.2-beta-branch

Contributors (Alphabetical Order)

Andras Banki-Horvath Olaoluwa Osuntokun Oliver Gugger Wilmer Paulino /laolu32@gmail.com