This commit breaks the `Resolve` into two parts - the first part is
moved into a `Launch` method that handles sending sweep requests, and
the second part remains in `Resolve` which handles waiting for the
spend. Since we are using both utxo nursery and sweeper at the same
time, to make sure this change doesn't break the existing behavior, we
implement the `Launch` as following,
- zero-fee htlc - handled by the sweeper
- direct output from the remote commit - handled by the sweeper
- legacy htlc - handled by the utxo nursery
This `immediate` flag was added as a hack so during a restart, the
pending resolvers would offer the inputs to the sweeper and ask it to
sweep them immediately. This is no longer need due to `blockbeat`, as
now during restart, a block is always sent to all subsystems via the
flow `ChainArb` -> `ChannelArb` -> resolvers -> sweeper. Thus, when
there are pending inputs offered, they will be processed by the sweeper
immediately.
The sweeper can handle the waiting so there's no need to wait for blocks
inside the resolvers. By offering the inputs prior to their mature
heights also guarantees the inputs with the same deadline are
aggregated.
Find and replace all nolint instances refering to the `lll` linter and
replace with `ll` which is the name of our custom version of the `lll`
linter which can be used to ignore log lines during linting.
The next commit will do the configuration of the custom linter and
disable the default one.
With this commit, we update all the resolvers to pass in the new htlc
resolution blobs. Along the way, we remove the old blocking guard on
this resolution logic for HTLCs with blobs.
In this commit, we bring the timeout resolver more in line with the
success resolver by using the sweeper to handle the HTLC offered remote
timeout outputs. These are outputs that we can sweep directly from the
remote party's commitment transaction when they broadcast their version
of the commitment transaction.
With this change, we slim down the scope slightly by only doing this for
anchor channels. Non-anchor channels will continue to use the
utxonursery for this output type for now.
This commit moves the offering of second-level outputs one block
earlier. The sweeper will check the required locktime and wait until it
matures. This is needed so the second-level outputs can be aggregated
properly.
`IncubateOutputs` never takes more than one HTLC, so we change the
params to be optional, which helps with the following commit where we
pass the deadline height when incubating outgoing HTLCs.
In this commit, we attempt to fix an issue that may lead to force closes due
to small value HTLCs. The sweeper has built in a "negative yield" heuristic
where it won't sweep something that'll result in paying more fees than the
HTLC amount. However for HTLCs, we want to always sweep them, as we don't
cancel back the HTLCs before the outgoing contract is fully resolved.
In the future, we'll start to make more uneconomical decisions about if we
should go to chain at all for small value HTLCs, and also do things like
cancel back early if the HTLC is small and we think we might be contested by
chain fees.
Previously when a block spend is found for the outpoint, our htlc
timeout resolver will do a checkpoint, which implicitly creates a db
record if there isn't one. Now, if the spend is found in mempool,
the resolver will be deleted once the contract is resolved. Later on
when the spend is found in the block again, the resolver will be created
again, but never gets resolved this time.
This commit extends the current htlc timeout resolver to also watch for
preimage spend in mempool for a full node backend.
If mempool enabled, the resolver will watch the spend of the htlc output
in mempool and blocks **concurrently**, as if they are independent.
Ideally, a transaction will first appear in mempool then in a block.
However, there's no guarantee it will appear in **our** mempool since
there's no global mempool, thus we need to watch the spend in two places
in case it doesn't go through our mempool.
The current design favors the spend event found in blocks, that is, when
the tx is confirmed, we'd abort the monitoring and conitnue since the
outpoint cannot be double spent and re-appear in mempool again. This is
not true in the rare case of reorg, and we will handle reorg seperately.
In this commit, we consolidate the _lease specific_ logic for the
success and timeout HTLC resolvers. We do this with the addition of a
new struct which is then composed via struct embedding with the two
existing structs. This fixes a flake in the integration tests by
ensuring the height is set up front, rather than eventually once the
height matches the lock time.
This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
In order to sweep the commitment and HTLC outputs belonging to a
script-enforced leased channel, each resolver must know whether the
additional CLTV clause on the channel initiator applies to them. To do
so, we retrieve the historical channel state stored within the database
and supplement it to the resolvers to provide them with what's needed in
order to sweep the necessary outputs and resolve their respective
contracts.
This commit moves the logic for sweeping the confirmed second-level
timeout transaction into its own method.
We do a small change to the logic: When setting the spending tx in the
report, we use the detected commitspend instead of the presigned tiemout
tx. This is to prepare for the coming change where the spending
transaction might actually be a re-signed timeout tx, and will therefore
have a different txid.
When a remote peer claims one of our outgoing htlcs on chain, we do
not care whether they claimed with multiple stages. We simply store
the claim outgome then forget the resolver.
