It's possible that a user might not want the Tor private key to sit on the disk in plaintext (it is a private key after all). So this commit adds a new flag to encrypt the Tor private key on disk using the wallet's seed. When the --tor.encryptkey flag is used, LND will still write the Tor key to the same file, however it will now be encrypted intead of plaintext. This essentially uses the same method to encrypt the Tor private key as is used to encrypt the Static Channel Backup file.
This allows the zero-conf and scid-alias feature bits to be toggled
using the config. The feature bits are off by default to protect users
from accidentally incurring the risk of a zero-conf channel.
Currently, the Bitcoind.Dir configuration option is used as the base
directory for locating both the bitcoind configuration file and the RPC
cookie file. However, it is quite common for Bitcoin Core to be packaged
in such a way that the configuration file and the RPC cookie file reside
in different directories: "/etc/bitcoin/bitcoin.conf" and
"/var/lib/bitcoind/.cookie".
This change makes it such that --bitcoind.config and
--bitcoind.rpccookie options can be specified to override the default
auto-detection logic, and if either is unspecified, the auto-detection
logic will still do its job.
This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
In this commit, we expose a new monitoring option to allow users to
export gRPC performance metrics. These metrics can be used to see how
long certain calls are taking, the total amount of time spent handling
calls, broken down by service and also call.
This option consumes additional memory and disk space for the Prometheus
server, which is why we're opting to make it an optional flag.
To enable converting an existing wallet with private key material into a
watch-only wallet on first startup with remote signing enabled, we add a
new flag. Since the conversion is a destructive process, this shouldn't
happen automatically just because remote signing is enabled.
Unfortunately, we can't use the graph cache directly here as it doesn't
include all the information we need, since it only includes the minimal
amount of information needed for path finding.
Instead, we use a simple mutex guarded cache that evicts itself after a
certain interval. The default is set small enough that most users
shouldn't really notice. We also provide a way to disable the cache, and
also disable the cache in the itests.
Fixes https://github.com/lightningnetwork/lnd/issues/1232
This commit adds a new health check, tor connection, to our liveness
monitor. A monitor refactor is applied to the server creation such that
the scope of health check creation is managed within one function.
With go 1.17 a change to the build flags was implemented:
https://go.googlesource.com/proposal/+/master/design/draft-gobuild.md
The formatter now automatically adds the forward-compatible build tag
format and the linter checks for them, so we need to include them in our
code.
In this commit we add an extra config for enabling logging to an
external file when using embedded etcd. This can be useful when running
integration tests to see more details about etcd related issues.
Since we're now storing the content of multiple previously distinct
database files in etcd, we want to properly namespace them as not to
provoke any key collisions. We append a sub namespace to the given
global namespace in order to still support multiple lnd nodes using the
same etcd database simultaneously.
Because the btcwallet code uses the legacy walletdb interface we must
assume it is not fully concurrency safe. Therefore we make sure only a
single writer can be active at any given time for the wallet DB backend
when using etcd.
To have all the database backend related code in one place, we finally
also move the initialization of the wallet DB loader option into the
GetBackends() method.
The final database that needs to be made remote compatible is the
watchtower server and client database.
They are handled a bit differently because both of them are not always
active, only when specifically turned on in the config.
Even though the sphinx router's persistent replay log is not crucial in
the operation of lnd as its state can be re-created by creating a new
brontide connection, we want to make lnd fully stateless and therefore
have the option of not storing any state on disk.
