Due to a recent change within the codebase to return estimated fee rates
in sat/kw, this commit ensures that we use this fee rate properly by
calculing a transaction's fees using its weight. This includes all of
the different transactions that are created within lnd (funding, sweeps,
etc.). On-chain transactions still rely on a sat/vbyte fee rate since it's
required by btcwallet.
In this commit, we modify our FeeEstimator interface to return an
estimated fee rate in sat/kw. Recently, due to low fees on the network,
users have been experiencing failures broadcasting transactions due to
not meeting specific fee requirements. This was happening more often
than not, as the estimated fee returned by backend nodes (bitcoind and
btcd) only takes into account vbytes, rather than weight. The fees
returned are also expressed in sat/kb, so we must take care that we do
not lose precision while converting to sat/kw. In the event that this
happens, a fee floor of 253 sat/kw has been added. This fee rate
originates from bitcoind rounding up the conversion from weight to
vbytes.
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.
Due to recent changes to the BitcoindClient interface, we now require
the backing bitcoind to use different hosts for its ZMQ raw block and
raw transaction notifications. This was needed as the notification queue
maintained by the bitcoind node would sometimes overflow with
transactions and cause block notifications to be dropped/missed.
In this commit, we expand extractBitcoindRPCParams to account for this.
In this commit, we update to the latest version of neutrino. This
version contains a number of bug fixes, and optimizations. Additionally
this version will allow the lnwallet re-org tests to once again pass
reliably on Travis.
In this commit, we fix a small bug where we would increase epochErrors
by one even if connections were successfully established. Due to this,
we would stay stuck inside of the peer bootstrapper loop without
requerying for new peers.
This commit fixes a potential race condition during
shutdown, that could allow the chain arb's
activeWatchers or activeChannels map to be modified
while ranging over their contents. We fix this by
copying the contents into new maps with the mutex
held, before releasing the mutex and shutting down
each watcher or channel arbitrator.
In this commit, we move the initialization of the server into the
funding manager itself. We do this as it's no longer the case that _any_
RPC needs to access the funding manager. In the past, this was the
only reason that the funding manager was instantiated outside of the
server: to be able to respond to queries _before_ the server was
started.
This change also fixes a bug as atm, the funding manager will try to
register for notifications _before_ the ChainNotifier itself has fully
started.
In this commit, we modify the test to explitlcy give the neutrino
backend more time to catch up compared to the RPC backends. We do this
as a recent change has been made in the neutrino backend to wait for the
filter headers to finish syncing before proceeding with the rescan
itself. As a result, we'll need to account for this in the test and
sleep enough to give the backend a chance to catch up.
In this commit, we update the convertToSecondLevelRevoke function to
also upgrade the second level pkScript as well. This is required as
we'll need to use this for a confirmation notification once we sweep the
output in the case that the remote party goes to the second layer.
In this commit, we update the NewBreachRetribution method to include
pkScripts for htlc outputs. We do this now, as the breach arbiter will
need the raw pkScript when attempting to request spend notifications for
each HTLC.
