To avoid the ChainService still attempting to access the database when
it gets closed, re-order the stop order such that the Chainservice gets
stopped before closing the DB.
In this commit, we fix an oversight that overrode the default ban
duration for neutrino to 5s from the default 24 hrs. We correct this by
raising the ban duration to 48hrs. In the future in order to ignore
these peers persistently, we'll need to start to persist our ban list.
However that's a change for another time.
In this commit, we upgrade regular KeyRing instance to a SecretKeyRing
instance as we need the upgraded instance in order to recover SCB's. Due
to the fact that we don't currently store the full KeyLocator for the
key used to derive a shachain root for each channel, we instead need to
obtain the private key vanilla to re-derive this value.
In this commit, we slightly refactor the startup of lnd when running
with a Neutrino light client backend. We'll now begin syncing our
backend as soon as lnd starts and passes all configuration checks. Since
this is all done before lnd's wallet setup, the light client will be
syncing in the background while the user notes/inputs their wallet seed.
This is done in order to provide a better UX from the point of the user,
such that most of the chain will already be synced by the time they get
to deposit funds into the wallet.
In this commit, we lower the default CLTV delta from 144 (1 day) to 40
blocks (~7 hours). We do this as the initial value was purposefully very
high, and was only in place as place holder in earlier versions of the
software. Such a high value can also discourage path finding algorithms
from taking lnd paths due to the negative impact of CLTV value in widely
deployed heuristics.
This commit is a step to split the lnwallet package. It puts the Input
interface and implementations in a separate package along with all their
dependencies from lnwallet.
In this commit, we fix a bug recently introduced where we would
construct the parameters required to connect to a bitcoind backend, but
never actually started the connection.
In this commit, we introduce a nice optimization with regards to lnd's
interaction with a bitcoind backend. Within lnd, we currently have three
different subsystems responsible for watching the chain: chainntnfs,
lnwallet, and routing/chainview. Each of these subsystems has an active
RPC and ZMQ connection to the underlying bitcoind node. This would incur
a toll on the underlying bitcoind node and would cause us to miss ZMQ
events, which are crucial to lnd. We remedy this issue by sharing the
same connection to a bitcoind node between the different clients within
lnd.
Now that we have a fallback method for when the transaction index is not
enabled, its requirement to be enabled for a full node is no longer
needed, so we can safely remove this check.
When in neutrino mode, it seems that the node is not closed during the cleanup, so if a block is received between the time the DB is closed and the server is closed (or if the process is still running after the server is shutdown like on a mobile app), the code panic's and crashes with:
panic: unable to write block header: database not open
goroutine 41 [running]:
github.com/lightningnetwork/lnd/vendor/github.com/lightninglabs/neutrino.(*blockManager).handleHeadersMsg(0x9a1ec0a0, 0x9a3e6030)
/ext-go/1/src/github.com/lightningnetwork/lnd/vendor/github.com/lightninglabs/neutrino/blockmanager.go:1164 +0x2224
github.com/lightningnetwork/lnd/vendor/github.com/lightninglabs/neutrino.(*blockManager).blockHandler(0x9a1ec0a0)
/ext-go/1/src/github.com/lightningnetwork/lnd/vendor/github.com/lightninglabs/neutrino/blockmanager.go:347 +0x3b4
created by github.com/lightningnetwork/lnd/vendor/github.com/lightninglabs/neutrino.(*blockManager).Start
/ext-go/1/src/github.com/lightningnetwork/lnd/vendor/github.com/lightninglabs/neutrino/blockmanager.go:200 +0xe8
Here's a log of shutdown before the change:
[INF] LTND: Gracefully shutting down the server...
[INF] FNDG: Funding manager shutting down
[INF] SPHX: Block epoch canceled, decaying hash log shutting down
[INF] CRTR: Channel Router shutting down
[INF] CRTR: FilteredChainView stopping
[INF] HSWC: HTLC Switch shutting down
[INF] UTXN: UTXO nursery shutting down
[INF] BRAR: Breach arbiter shutting down
[INF] DISC: Authenticated Gossiper is stopping
[INF] CNCT: Stopping ChainArbitrator
[INF] LTND: Shutdown complete
And here's a log of shutdown after the change:
[INF] LTND: Gracefully shutting down the server...
[INF] FNDG: Funding manager shutting down
[INF] SPHX: Block epoch canceled, decaying hash log shutting down
[INF] CRTR: Channel Router shutting down
[INF] CRTR: FilteredChainView stopping
[INF] HSWC: HTLC Switch shutting down
[INF] UTXN: UTXO nursery shutting down
[INF] BRAR: Breach arbiter shutting down
[INF] DISC: Authenticated Gossiper is stopping
[INF] CNCT: Stopping ChainArbitrator
[INF] LTND: Shutdown complete
[INF] BTCN: Block manager shutting down
[INF] BTCN: Address manager shutting down
In this commit, we modify our initialization of neutrino to also pass
in the custom dialer and name resolver function. With this change, if
lnd is configured to use Tor, then neutrino will as well. This means
that *both* the Bitcoin P2P as well as the Lightning P2P traffic will
be proxied over Tor.
This commit factors out the btcd and ltcd options into their own sections
similar to neutrino, and adds a bitcoind section as well. Now, you specify
node options similarly to:
--ltcd.rpchost=...
or
--btcd.rpcuser=...
or
--bitcoind.zmqpath=...
For Bitcoin, you specify an alternate back-end to btcd as follows:
--bitcoin.node=bitcoind
or
--bitcoin.node=neutrino
You can also specify the default option:
--bitcoin.node=btcd
For Litecoin, only `btcd` mode is valid, and corresponds to the `ltcd`
section. For example:
--litecoin.node=btcd
--ltcd.rpchost=...
The new code also attempts to read the correct options and auth info
from bitcoin.conf just as it does from btcd.conf/ltcd.conf.
This commit removes the definitions of
defaultBitcoinForwardingPolicy and defaultLitecoinForwardingPolicy
from the the chainregistry, and instead creates a routingPolicy
from the values found in the config.
