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.
As requested by users of node bundle software. They want to use the
wallet-unlock-password-file configuration option in their
default/template config file. This makes the first-time lnd setup a bit
more tricky since lnd will fail with an error if no wallet exists yet
while that config option is used.
The new wallet-unlock-allow-create option instructs lnd to not fail if
no wallet exists yet but instead spin up its unlocker RPC as it would
without the wallet-unlock-password-file being present.
This is not recommended for auto-provisioned or high-security systems
because the wallet creation RPC is unauthenticated and an attacker could
inject a seed while lnd is in that state.
This commit adds height-based invoice expiry for hodl invoices
that have active htlcs. This allows us to cancel our intentionally
held htlcs before channels are force closed. We only add this for
hodl invoices because we expect regular invoices to automatically
be resolved.
We still keep hodl invoices in the time-based expiry queue,
because we want to expire open invoices that reach their timeout
before any htlcs are added. Since htlcs are added after the
invoice is created, we add new htlcs as they arrive in the
invoice registry. In this commit, we allow adding of duplicate
entries for an invoice to be added to the expiry queue as each
htlc arrives to keep implementation simple. Our cancellation
logic can already handle the case where an entry is already
canceled, so this is ok.
In automated or unattended setups such as cluster/container
environments, unlocking the wallet through RPC presents a set of
challenges. Usually the password is present as a file somewhere in the
container already anyway so we might also just read it from there.
This commit also changes the order of DB init to be run after the RPC
server is up. This will allow us to later add an RPC endpoint to be used
to query leadership status.
The --profile flag now accepts both a port and a host:port string.
If profile is set to a port, then pprof debugging information will
be served over localhost. Otherwise, we will attempt to serve pprof
information on the specified host:port (if we are allowed to listen
on it.)
We default to the safe option as if the port is connectable, anybody
can connect and see debugging information.
See: https://mmcloughlin.com/posts/your-pprof-is-showing
This commit adds a new config option: "--coop-close-target-confs"
which allows a user to override the default target confirmations of 6
that is used to estimate a fee rate to use during a co-op closure
initiated by a remote peer.
A new top level feeurl option was added recently to replace the neutrino.feeurl
option. The new option was never added to the sample config file and the
text was never updated to reflect that the option is required for
neutrino on mainnet. We fix this and also add a valid mainnet example
URL to the sample config file.
This commit caps the update fee the initiator will send when the anchors
channel type is used. We do not limit anything on the receiver side.
10 sat/vbyte is the current default max fee rate we use. This should be
enough to ensure propagation before anchoring down the commitment
transaction.
In certain container set ups, it's useful to optionally have lnd just shutdown if it detects that its certs are expired, as assuming there's a hypervisor to restart the container/pod, then upon restart, lnd will have fully up to date certs.
To allow nodes more control over the amount of time that their funds
will be locked up, we add a MaxLocalCSVDelay option which sets the
maximum csv delay we will accept for all channels. We default to the
existing constant of 10000, and set a sane minimum on this value so that
clients cannot set unreasonably low maximum csv delays which will result
in their node rejecting all channels.
To make it possible to request a Let's Encrypt certificate by using a
different IP address where the port 80 might still be free, we add the
IP part to its configuration as well instead of just the port.
This makes it possible to use an IPv6 address for the ACME request if
all available IPv4 addresses already have their port 80 occupied.
