With the introduction of additional payload fields for mpp, it becomes
a necessity to have their values available in the on-chain resolution
flow. The incoming contest resolver notifies the invoice registry of the
arrival of a payment and needs to supply all parameters for the registry
to validate the htlc.
In this commit, we fix an existing bug in the package, causing
resolutions to be restarted without their required supplementary
information. This can happen if a distinct HTLC set gets confirmed
compared to the HTLCs that we may have had our commitment at time of
close. Due to this bug, on restart certain HTLCS would be rejected as
they would present their state to the invoice registry, but be rejected
due to checks such as amount value.
To fix this, we'll now pass in the set of confirmed HTLCs into the
resolvers when we re-launch them, giving us access to all the
information we need to supplement the HTLCS.
We also add a new test that ensures that the proper fields of a resolver
are set after a restart.
In this commit, we create a new channel arb test context struct as the
current `createTestChannelArbitrator` has several return parameters, and
upcoming changes will likely at first glance need to add one or more
additional parameters. Rather than extend the existing set of return
parameters, we opt to instead create this struct that wraps the existing
state.
Along the way we add several new utility methods to this context, and
use them in the existing tests where applicable:
* `AssertStateTransitions`
* `AssertState`
* `Restart`
* `CleanUp`
Earlier the channel arbitrator would fail to recognize channels pending
close that were in the breached state. This lead to the state machine
not progressing correctly, and in some cases crashing since we would
attempt to force close an already closed channel.
A test TestChannelArbitratorForceCloseBreachedChannel is added to
exercise one of these scenarios.
Earlier we would not react to breaches, as these are handled by other
subsystems. Now we advances our state machine in case of breach, such
that we'll gracefully exit, and won't have leftover state in case of a
restart.
A simple test TestChannelArbitratorBreachClose to exercise this behavior
is added.
This commit fixes the 'unable to find incoming resolution' error that
occured when trying to resolve incoming htlcs below the dust limit that
are not actually present on the commitment tx.
In this commit, we make a series of changes to ensure that we'll be able
to properly survive restarts if we crash right after we call
MarkChannelClosed. In order to ensure we can survive restarts, we'll now
long the confirmed CommitSet to disk right before we close the channel.
Upon restart, we'll read these from disk so we can pick up where we left
over.
Additionally, we also will now consult the legacy chain actions if it
turns out that the channel has been closed, but we don't have a
confCommitSet written to disk. This will only be the case for nodes that
had pending close channels before this commitment.
In this commit, we fix a lingering TOOD statement in the channel arb.
Before this commitment, we would simply wipe our our local HTLC set of
the HTLC set that was on the remote commitment transaction on force
close. This was incorrect as if our commitment transaction had an HTLC
that the remote commitment didn't, then we would fail to cancel that
back, and cause both channels to time out on chain.
In order to remedy this, we introduce a new `HtlcSetKey` struct to track
all 3 possible in-flight set of HTLCs: ours, theirs, and their pending.
We also we start to tack on additional data to all the unilateral close
messages we send to subscribers. This new data is the CommitSet, or the
set of valid commitments at channel closure time. This new information
will be used by the channel arb in an upcoming commit to ensure it will
cancel back HTLCs in the case of split commitment state.
Finally, we start to thread through an optional *CommitSet to the
advanceState method. This additional information will give the channel
arb addition information it needs to ensure it properly cancels back
HTLCs that are about to time out or may time out depending on which
commitment is played.
Within the htlcswitch pakage, we modify the `SignNextCommitment` method
to return the new set of pending HTLCs for the remote party's commitment
transaction and `ReceiveRevocation` to return the latest set of
commitment transactions on the remote party's commitment as well. This
is a preparatory change which is part of a larger change to address a
lingering TODO in the cnct.
Additionally, rather than just send of the set of HTLCs after the we
revoke, we'll also send of the set of HTLCs after the remote party
revokes, and we create a pending commitment state for it.
This commits exposes the various parameters around going to chain and
accepting htlcs in a clear way.
In addition to this, it reverts those parameters to what they were
before the merge of commit d1076271456bdab1625ea6b52b93ca3e1bd9aed9.
In this commit, we simplify the existing `htlcTImeoutResolver` with some
newly refactored out methods from the `htlcTimeoutContestResolver`. The
resulting logic is easier to follow as it's more linear, and only deals
with spend notifications rather than both spend _and_ confirmation
notifications.
Previously a function pointer was passed to chain arbitrator to avoid a
circular dependency. Now that the routetypes package exists, we can pass
the full invoice registry to chain arbitrator.
This is a preparation to be able to use other invoice registry methods
in contract resolvers.
Previously the arbitrator wasn't advanced to the final stage after
the last contract resolved.
Also channel arbitrator now does not ignore a log error anymore
unresolved contracts cannot be retrieved.
This commit is a step to split the lnwallet package. It puts the Input
interface and implementations in a separate package along with all their
dependencies from lnwallet.
In this commit, we extend the htlcSuccessResolver to settle the invoice,
if any, of the corresponding on-chain HTLC sweep. This ensures that the
invoice state is consistent as when claiming the HTLC "off-chain".
In this commit, we prevent the ChainArbitrator from sending a force
close request for a channel if it has previously already sent one. We do
this to prevent blocking the caller of ForceCloseContract.
This commit moves the responsibility for closing local and remote force
closes in the database from the chain watcher to the channel arbitrator.
We do this because we previously would close the channel in the
database, before sending the event to the channel arbitrator. This could
lead to a situation where the channel was marked closed, but the channel
arbitrator didn't receive the event before shutdown. As we don't listen
for chain events for channels that are closed, those channels would be
stuck in the pending close state forever, as the channel arbitrator
state machine wouldn't progress.
We fix this by letting the ChannelArbitrator close the channel in the
database. After the contract resolutions are logged (in the state
callback before transitioning to StateContractClosed) we mark the
channel closed in the database. This way we make sure that it is marked
closed only if the resolutions have been successfully persisted.
This commit adds a test for the case where the ChannelArbitrator fails
to broadcast its commitment during a force close because of
ErrDoubleSpend. We test that in this case it will still wait for a
commitment getting confirmed in-chain, then resolve.
This commit adds MVP unit tests for the following scenarios in the
ChannelArbitrator:
1) A cooperative close is confirmed.
2) A remote force close is confirmed.
3) A local force close is requested and confirmed.
4) A local force close is requested, but a remote force close gets
confirmed.
In this commit, we add the primary struct of the package with a full
implementation. The duty of the ChannelArbitrator is to watch the set
of active contracts on a comment transaction and act accordingly if any
of their redemption criteria have been met. Potential criteria include:
an HTLC about to time out, and HTLC about to time out that we know the
preiamge to, or the remote party going to chain (forcing us to resolve
all pending contracts on chain).
The primary goroutine of this struct implements a persistent state
machine in order to ensure that mid contract resolution, we’re able to
properly survive restarts without losing our place, or forgetting about
a pending contract.
A ChannelArbitrator will stay alive until all contracts have been fully
resolved. This means that outside sub-systems no longer need to worry
about remembering to mark a channel as fully resolved, as it’s the job
of the ChannelArbitrator to do this task.
