Downloading every block that contains a channel point takes a very long
time when syncing the graph on mainnet with Neutrino. Therefore it makes
sense to use routing.assumechanvalid=true since by using Neutrino a user
already accepts the different trust model.
Apparently the existence or meaning of the routing.assumechanvalid flag
is unknown to a lot of users and is overlooked.
This commit basically sets the default to routing.assumechanvalid=true
for Neutrino. Because the CLI library doesn't support setting a bool
value to false by the user if the default is true, we need to add an
additional flag that is the inverse of the routing one, just for the
case where a Neutrino user explicitly wants to turn on channel
validation.
In this commit, we update to the latest version of neutrino that
includes some GC/perf optimizations when syncing, an exposed block
cache, and also additional filter verification for downloaded filters.
This PR was created in order to help to debug the failures in:
https://github.com/lightningnetwork/lnd/issues/5113
We add some more contextual errors so we can figure out where the
assumptions of the current scan to delete function in the invoice
registry is incorrect.
After unification of the WalletUnlocker and RPC services on the same gRPC
server, the WalletUnlocker will no longer be shut down after the wallet
has been unlocked.
In case --no-macaroons was used, this lead to the caller getting stuck
after unlocking the wallet, since we would wait for a response on the
MacResponseChan. Earlier we would close the MacResponseChan always
when shutting down the WalletUnlocker, but this is no longer done.
To fix this we close this channel after the wallet is unlocked,
regardless of which combination of --no-macaroons and --noseedbackup
that is being used.
This commit makes us gate the calls to the RPC servers according to the
current RPC state. This ensures we won't try to call the RPC server
before it has been fully initialized, and that we won't call the
walletUnlocker after the wallet already has been unlocked.
This commit achieves what we have been building up to: running the
WalletUnlockerService and the LightningService on the same gRPC server
simultaneously!
To achieve this, we first create the RPC server in a "interface only"
way, only creating the struct and setting the dependencies we have
available before the wallet has been unlocked. After the wallet has been
unlocked and we have created all the subsystems we need, we add those to
the RPC server, and start the sub-servers.
This means that the WalletUnlockerService and the LightningService both
will be registered and available at all times on the gRPC server.
However, before the wallet has been unlocked, the LightningService
should not be used since the RPC server is not yet ready to handle the
calls. Similarly, after the wallet has been unlocked, the
WalletUnlockerService should not be used. This we will ensure in
following commits.
