The bitcoind .cookie contains an autogenerated user (__cookie__) and
password (random string), which can be used instead of the rpc user name
and password. This commit allows for running against bitcoind without
having to access bitcoin.conf like in the case for pure
user/password/zmq configuration.
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
This clarifies the usage of the `externalhosts` option and brings its
documentation in line with similar options such as `externalip`.
Related issue: #6141
[skip ci]
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.
Fixes#5927.
This commit moves the code that attempts to create parent directories to
the correct place _after_ we've adjusted all path values to point to the
correct places. Before this commit the macaroon and tor paths would
point to their default locations, even if the --lnddir flag was
specified.
With this commit we standardize the error messages in the config parsing
section of the main package. We only print to stdout/stderr in a single
place and also make sure the same error is printed to the log (which
might or might not yet be initialized at that point).
In the case where lnd's config struct is embedded inside another struct
(for example in lightning-terminal), the flag won't be found under its
original name. So we try to also look it up under the prefixed name.
To make it possible to supply our own implementation of a secret key
ring, we extract that part from the chain control and split the whole
chain control creation into two parts.
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 this commit we extract the wallet creation/unlocking and
initialization completely out of the main function. This will allow us
to use custom implementations in the future.
As a preparation for making more and more implementation details
configurable, we add a new ImplementationCfg struct that houses all the
interfaces that can be defined externally.
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.
The wallet and macaroon databases are the first files that are created
for a new node. When initializing those databases, the parent directory
is created if it does not exist.
With both of the databases now potentially being remote, that code that
creates the parent directory might never be executed and we need to do
that manually when parsing the configuration.
Otherwise we run into an error when we later try to create our default
macaroons in that folder and it doesn't exist.
As a preparation to not have a local and remote version of the database
around anymore, we rename the variables into what their actual function
is. In case of the RPC server we even directly use the channel graph
instead of the DB instance. This should allow us to extract the channel
graph into its own, separate database (perhaps with better access
characteristics) in the future.
