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.
In this commit, we add a new runtime assertion to ensure that the
backed btcd node (if this mode is active) has the proper indexes set
up. Atm, if btcd isn’t running with the txindex active, then the
current ChainNotifier implementation will be unable to properly handle
certain classes of historical notification dispatches.
In order to test that the running btcd node is configured properly,
we’ll fetch the latest block, then try to query a transaction within
that block using the txindex. If btcd isn’t running with this mode
active, then the request will fail. In this case, we’ll then fail to
start lnd with an error.
Fixes#525.
In this commit we ensure the behavior of lnd with the —noencryptwallet
command line option heaves as it did before user initiated wallet
encryption was implemented. We do this by modifying the
waitForWalletPassword method to instead return two pass phrases: one
public and one private. The default wallet public passphrase is then
restarted back to the value which was used stoically in the codebase
before the latest merged PR.
This let the caller of newChainControlFromConfig set the password
to be used when creating or unlocking the wallet database. The
provided password is used both as private and public password.
This commit fixes a bug wherein the wallet would use the default relay
fee to craft transactions. On testnet, this might be insufficient or be
rejected all together in a mainnet setting. Therefore, we now pass in
the FeeEstimator interface and ensure that it’s consulted in order to
set the relay fee the wallet will use to craft transactions.
Note that this is a hold over until we have true dynamic fee
calculation within lnd which can then be extended to the internal
wallets.
This commit finishes up the implementation of newChainControlFromConfig
in order to properly initiate the members of the chainControl struct
when the new light client mode (neutrino). With this lnd is now able to
switch over to either mode with a simple configuration change.
This commit adds a new agent to the codebase: the chainRegistry. In a
multi-chain future, the chainRegistry will be the dispatch point
capable of mapping cross-chain parameters, and a particular chain to
the chainControl for that chain. The chainControl struct encompasses
the 3 primary interfaces used within the daemon to register for events,
and drive other workflows.
