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.
In this commit, we modify the watch tower to use P2TR addrs for just
about anything sweep related.
One eye sore in this diff are the changes to
`backup_task_internal_test.go`. All the values are hard coded, and now
either differ by a value of 48, or needed to be modified to account for
the new assumptions propagated to rewards values and fees.
It turns out that when a REST call to an endpoint (in this specific
example /v1/payments, which for GET returns all payments but for DELETE
removes all payments) is made with POST instead of the correct
registered method, the grpc-gateway tried to find a fallback method.
That resulted in randomly choosing between any of the calls with the
same URI pattern.
This is of course catasrophic if the user attempts to query the list of
payments (but using POST instead of GET by accident) and then ending up
calling the DELETE endpoint instead.
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
Fixes#5936.
This commit makes sure every error that causes the Main() function to
return is logged to the log file in addition to being printed to stderr.
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).
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.
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.
We move some of the wallet related functions into the new file that
houses the new customizable implementations for some of our interfaces.
Since the next customizable interface will be the wallet, we move those
wallet and chain backend related helper functions.
NOTE: This is a pure code move.
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.
As a preparation for extracting the wallet related initialization code,
we first need to separate the purely configuration related chain control
initialization from the wallet related code. We do that by splitting the
chain control into a partial and full struct that is initialized in two
parts. This also allows us to create the wallet configuration itself
outside of the chain control package and we need to thread through fewer
parameters through the chain control config.
To remove one more direct dependency to a variable in our main function,
we pass in the required parameter to the autopilot only instead of the
whole chain configuration.
We'll refactor the wallet creation and unlock process in a following
commit and want to make it possible to not need a direct reference to
the macaroon service in our main function. Since we store it in the
interceptor chain anyway (if we're using macaroons in the first place),
we might as well use the instance there directly.
The block cache size in the chainreg.Config previously wasn't used but
instead the block cache was passed in as a separate parameter. We
replace the cache size with the actual cache in the config to streamline
things somewhat.
To avoid the channel map needing to be re-grown while we fill the cache
initially, we might as well pre-allocate it with a somewhat sane value
to decrease the number of grow events.
With the middleware handler in place, we now need to add a new gRPC
interceptor to the interceptor chain that will send messages to the
registered middlewares for each event that could be of interest to them.
Fixes#4383 by adding a new SafeCopyMacaroon function that correctly
clones all caveats and prevents modifications on the copy from affecting
the original.
In addition to creating a new wallet from an aezeed, we allow specifying
an exteded master root key as the main wallet key directly.
Because an exteded key (xprv) doesn't contain any information about the
creation time of the wallet, we must assume a birthday to start scanning
the chain from (if the user doesn't provide an explicit value). Since
lnd only uses SegWit addresses, it makes sense to
choose the date that corresponds to the first mainnet block that
contained SegWit transactions.
Restoring a wallet from an extended master root key will result in a
significantly longer initial wallet rescan time if the default value is
used.
This adds support for notifying systemd about the state of LND. It
notifies systemd just before waiting for wallet password or, if
`wallet-password-file` was specified, right after unlocking the wallet.
This means that "ready" represents RPC being available for intended use.
It's intentional, so that client services can use `After=` in `systemd`
configuration to avoid misleading error messages about missing files or
refused connections.
Part of #4470
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.
The macaroon root keys should also be stored to the remote database if a
replicated backend such as etcd is used.
This commit refactors the macaroons service and wallet unlocker to
accept a kvdb backend directly instead of creating the bolt instance
automatically.
This commit gets rid of the concept of a local and remote database when
etcd is used. Instead the same backend is now used for both the
(previously renamed from local and remote DB) graph and channel state
databases.
This will make path finding extremely slow on etcd and will require
further optimizations and possibly a write-through cache for the graph
DB. But this is a requirement for making lnd itself fully stateless.
In order to separate our databases more clearly, we refactor the height
hint cache DB to use a kvdb backend instead of the channel DB instance
directly.
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 a preparation to initialize more than just the channel database on
startup we introduce a new struct that holds a reference to each of our
database instances.
This changes file reation mode on admin macaroon from 0600 to 0640. The
reason is to make permission management easier.
Closes#4385
**Is this safe?**
Yes, it is. Assuming a reasonably secure Linux system, it will have a
separate group for each user. E.g. a new user `lnd` gets assigned group
`lnd` which nothing else belongs to. A system that does not do this is
inherently broken already.
Since there is no other user in the group, no other user can read admin
macaroon unless the administrator explicitly allowed it. Thus there's no
harm allowing group read.
