This commit is a preparation for the implementation of remote spend
detection. Remote spends may happen before we broadcast our own sweep
tx. This calls for accurate height hints.
In this commit, we modify the newly introduced UtxoSweeper.CreateSweepTx
to accept the confirmation target as a param of the method rather than a
struct level variable. We do this as this allows each caller to decide
at sweep time, what the fee rate should be, rather than using a global
value that is meant to work in all scenarios. For example, anytime
we're sweeping an output with a CLTV lock that's has a dependant
transaction we need to sweep/cancel, we may require a higher fee rate
than a regular force close with a CSV output.
This commit attempts to fix an inconsistency in when we consider an HTLC
to expire. When we first launched the resolver we would compare the
current block height against the expiry, while for new incoming blocks
we would compare against expiry-1.
This lead to a flake during integration tests, during a call to
RestartNode after _exactly_ enough blocks for the HTLC to expire. In
some cases the resolver would see the new blocks and consider the HTLC
to be expired (because of the -1), while in some cases resolver would
shut down before seeing the new blocks, and upon restart wouldn't act on
the new height because we did not compare against -1.
This commit fixes this by doing the same comparison in both cases.
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.
This commit fixes a potential race condition within the
IncomingContestResolver, that could cause us to miss a
preimage that was delivered in time.
Currently we query the db for the preimage, and then
subscribe for notifications. This permits the following
ordering of events:
- query for preimage, returns nothing
- preimage is added and delivered to subscribers
- subscribe to preimages
- preimage never comes through!!
We fix this by reordering to subscribe for preimages and
then query just in case it already exists. The effect is
that the query will always return a valid read of the
preimages that are currently queued for delivery.
In this commit, we fix an existing grouting leak within the contract
court package. If a goroutine dies, but it doesn’t actually cancel the
block epoch notification that it requested, then it’s possible to leak
thousands of gorutines. To remedy this situation, we ensure that we’ll
*always* cancel the epoch notification once the goroutine has exited.
In this commit, we fix an existing flake on Travis related to the new
set of on-chain HTLC tests. In this timing flake, Bob would broadcast
his sweeping transaction, but *mid block mining*. As a result, the
output would never be properly swept, needing an additional block to be
mined. We’ll now wait for both Bob’s sweeping transaction, and Carol’s
sweep transaction to be confirmed before we attempt our assertions.
In this commit, we fix an existing bug in the implementation of the
resolution of the htlcOutgoingContestResolver. Before this commit, we
would _always_ watch the claim outpoint. However, if this is on the
remote party’s commitment transaction, then we would end up watching
the wrong output. We’ll now properly detect this by modifying which
output we watch, based on if we have a second level transaction or not.
In this commit, we add 6 new integration tests to test the various
actions that may need to be performed when either side goes on-chain to
fully resolve HTLC’s. Many of the tests are mirrors of each other as
they test sweeping/resolving HTLC’s from both commitment transactions.
In this commit, we introduce a new interface, the ContractResolver. The
duty of a ContractResolver is to watch a contract on-chain, for all
possible transitions, and exit finally when the contract has been fully
resolved. Resolvers themselves can be recursive: meaning producing
another resolver to hand off the duties require to fully resolve a
contract.
Each resolver also has a ResolverKit which contains all the function
closures and interfaces that the resolver need to properly do its job.
The 5 types of resolvers are:
* outgoing HTLC timeout
* outgoing HTLC contested
* incoming HTLC know presage
* incoming HTLC contested (don’t yet know)
* commitment sweep
In the future, more advanced resolver types can be added as required.
