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.
