In this commit, we modify the logic surrounding sweeping outputs to be
aware of the new types of outputs that the nursery is now responsible
for. Namely: incoming HTLC’s on our commitment transaction as well as
outgoing HTLC’s on the commitment transaction for the remote party. For
the latter class of HTLC, we’ll now set the lock time on the sweeping
transaction in order to satisfy the CLTV clause in the output we’re
spending.
The utxo nursery is now responsible for two additional output types:
outgoing HTLC’s on the commitment transaction of the remote party, and
second-level claim transactions that we broadcast. In this commit,
we’ve updated the NurseryReport to now include details, so users are
able to properly keep track of the status of all their pending coins.
This new field is reserved for outgoing HTLC outputs on the commitment
transaction of the remote party. These outputs don’t have a CSV delay,
but instead have an absolute maturity time.
In this commit, rather than the IncubateOutputs method taking a close
summary entirely, we now take resolutions for each possible output
type. We do this as it’s possible that each output is sent for
incubation at a different time as on-chain conditions change.
Additionally, if we get a baby output (CLTV locked transaction), we’ll
check to see if we can immediately broadcast it. Otherwise, we may
never sweep it unless a restart is attempted.
In this commit, we address a lingering TODO: before this if we had a
set of HTLC’s that we knew the pre-image to on our commitment
transaction after a restart, then we wouldn’t attempt to settle them.
With this new change, we’ll check that we didn’t already retransmit the
settles for them, and check the preimage cache to see if we already
know the preimage. If we do, then we’ll immediately settle them.
In this commit, we add some additional logic to the case when we
receive a pre-image from an upstream peer. We’ll immediately add it to
the witness cache, as an incoming HTLC might be waiting on-chain to
fully resolve the HTLC with knowledge of the newly discovered
pre-image.
In this commit, we add a new method: ProcessContractResolution. This
will be used by entities of the contract court package to notify us
whenever they discover that we can resolve an incoming contract
off-chain after the outgoing contract was fully resolved on-chain.
We’ll take a contractcourt.ResolutionMsg and map it to the proper
internal package so we can fully resolve an active circuit.
In this commit, we add the preimageBeacon which is an implementation
of both the contractcourt.WitnessBeacon and lnwallet.PreimageCache
interfaces. This will be used when closing channels to check to see if
the know the preimage, and also to communicate to any active contract
resolvers once we discover a preimage either on-chain or off-chain.
In this commit, we add the WitnessCache sub-storage system of the
greater database. The WitnessCache is a persistent cache of all
witnesses we’ve encountered on the network. We’ll use this cache to
share any on-chain discoveries between active channels. Eventually
we’ll also use this to enforce the variant that a preimage is only to
be used ONCE on the network.
In this commit, we remove all the code win the BreachArbiter that was
dedicated to sweeping output on the remote party’s commitment
transaction, and also responding to unilateral channel closes. We no
longer need to do this, as this is now the duty of the
ChannelArbitrator.
In this commit, we add the ChainArbitrator struct. The ChainArbitrator
is a special sub-system that will oversee the on-chain resolution of
all active channels, and also channels that are in the pending close
state. The ChainArbitrator maintains a set of ChannelArbitrators, one
for each channel that hasn’t yet been fully resolved.
Outside sub-systems should send new channels to the arbitrator once
they’ve opened. Additionally, they can also trigger manual
interventions to close out a channel on chain forcibly, or just to
signal that a channel has been closed cooperatively.
Finally, (for now) the ChainArbitrator should be notified once a fresh
set of signals for a channel becomes available. The ChannelArbitrator
for the channel will use these set of signals to be notified when an
on-chain event happens.
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.
In this commit, we add a new file: briefcase.go. The contents of this
file are the ArbitratorLog. This log will be used by the internal state
machine of each Channel Arbitrator to ensure that each state transition
is fully reflected on-disk, to ensure that the state machine is durable
and able to survive restarts.
This commit also adds a new implementation of the ArbitratorLog
interface backed by boltdb.
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.
In this commit, we now account for a case where a node sends us a
FailPermanentChannelFailure during a payment attempt. Before this
commit, we wouldn’t properly prune the edge to avoid re-using it. We
remedy this by properly attempting to prune the edge if possible.
Future changes well send a FailPermanentChannelFailure in the case that
we ned to go on-chain for an outgoing HTLC, and cancel back the
incoming HTLC.
In this commit, we add a new test case for unilateral channel closes to
ensure that if the remote party closes the commitment on-chain. Then
we’re able to sweep both incoming and outgoing HTLC’s from their
commitment. With this tests, we ensure that the values returned for
HtlcResolutions from the UnilateralCloseSummary are correct and allow
us to sweep all funds properly.
In this commit we add some additional scenarios to the TestForceClose
test. With this expanded test case, we now ensure the the party that
force closes is able to properly sweep both incoming and outgoing
HTLC’s fully with the information contained the HtlcResolution struct.
In this commit, we update the channel state machine tests to use a new
key for each purpose. Before this commit, the same key would be used
the entire time. As a result, a few bugs slipped by that would’ve been
detected if we used fresh keys for each purpose. Additionally, this
reflect the real world case as we always use distinct keys for each
purpose to avoid key re-use.
In this commit, we’ve added a new HtlcResolutions struct to house both
the incoming and outgoing HTLC resolutions. This struct will now be
coupled with the object that returns when we detect that a commitment
transaction was closed on chain. For incoming HTLC’s, we’ll check the
preimage cache to see if we can claim the HTLC on-chain. If we can,
then we’ll copy of the preimage, and make a proper incoming HTLC
resolution.
In this commit, we modify the OutgoingHtlcResolution struct to detect
if this is the remote party’s commitment transaction or not. With this
change, we’ll now be able to properly time out an HTLC that was
detected on the commitment transaction of the remote peer.
Additionally, we now populate the CsvDelay (if local commitment) and
the ClaimOutpoint (as we may be sweeping directly from the commitment
transaction now.
In this commit, we add a new IncomingHtlcResolution struct. This is the
opposite of the existing OutgoingHtlcResolution struct. The items in
this new struct allow callers to sweep an incoming HTLC that we know
the preimage to. These will always be created when a commitment goes
on-chain. However, if we know the preimage, then that will be populated
in place of all zeroes in the Preimage field.
In this commit, we modify both the ForceCloseSummary, and the
UnilateralClosureSummary to return the items needed to sweep the
commitment output distinctly. By doing this, it’s now possible to pass
a dedicated struct to a sub-system in order to allow it to sweep a
commitment output. As the maturity delay is a part of this new struct,
this tells the caller if this was on the local commitment (CSV
required) or on the remote commitment (no CSV required).
In this commit, we’ve added a new method to the channel state machine:
ActiveHtlcs. This method will allow callers to poll the state of the
channel to retrieve the set of HTLC’s active on *both* commitment
transactions.
In this commit, we modify the RevokeCurrentCommitment method to now
return the set of active HTLC’s. This will be used by callers in the
future to update other sub-systems when the set of HTLC’s on the
commitment changes, and can also be used on the RPC level to
synchronize systems level integration tests.
By returning a *TxWeightEstimator from each method, we now all callers
to chain the methods. This adds a bit of nice sugar when interacting
with the struct.
In this commit, we rename several of the existing WitnessType
definitions to be more descriptive than they were previously. We also
add a number of additional types which we need to handle scripts for,
but weren’t yet added before. Finally, we modify the
receiverHtlcSpendTimeout to optionally take an additional parameter to
set the locktime of the spending transaction accordingly. This final
modification allows the caller to specify that the lock time has
already been set on the main transaction.
