Commit Graph

33 Commits

Author SHA1 Message Date
Joost Jager
3d7de2ad39
multi: remove dead code 2019-09-10 17:21:59 +02:00
Olaoluwa Osuntokun
2011ccc571
contractcourt: write confirmed CommitSet to disk before MarkChannelClosed
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.
2019-05-27 15:26:46 -07:00
Olaoluwa Osuntokun
086f4eb8b3
contractcourt: add new TestChannelArbitratorDanglingCommitForceClose test 2019-05-27 15:26:43 -07:00
Olaoluwa Osuntokun
b4a116fd07
contractcourt: update TestChannelArbitratorLocalForceClosePendingHtlc to assert resolution msg delivery 2019-05-27 15:26:42 -07:00
Olaoluwa Osuntokun
5f0fad85be multi: address lingering TODO by no longer wiping out local HTLCs on remote close
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.
2019-05-27 14:34:13 -07:00
Johan T. Halseth
10070ecab7
lnwallet: make BlockChainIO.GetUTXO take cancel chan
Use quit channels as cancel chan for call to GetUTXO.
2019-05-09 14:44:47 +02:00
Johan T. Halseth
beb5d14ed9
lnwallet/btcwallet: add compile time check for BlockChainIO interface 2019-05-09 14:44:41 +02:00
Joost Jager
ab4da0f53d
cnct: define separate broadcast delta for outgoing htlcs
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.
2019-04-05 11:36:07 +02:00
Olaoluwa Osuntokun
6b24b6dabd
contractcourt: simplify htlcTimeoutResolver, unify with HTLC contest logic
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.
2019-03-19 16:50:27 -07:00
Joost Jager
449c3d533e
contractcourt: add access to full invoice registry from resolvers
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.
2019-03-15 10:08:35 +01:00
Olaoluwa Osuntokun
4af857f0c6
Merge pull request #2356 from joostjager/invoices-subserver
invoices: add subscribesingleinvoice
2019-02-01 17:19:58 -08:00
Joost Jager
bacd92418a
invoices: use lntypes.Hash and lntypes.Preimage
Previously chainhash.Hash was used, which converts to/from string in
reversed format. Payment hashes and preimages are supposed to be
non-reversed.
2019-02-01 09:42:29 +01:00
Joost Jager
9abe06f3c8
cnct: finish channel arbitrator in StateFullyResolved
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.
2019-02-01 09:10:04 +01:00
Joost Jager
9e012ecc93
multi: move Input interface and related code
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.
2019-01-31 13:25:33 +01:00
Wilmer Paulino
41f638c7cf
contractcourt+server: settle invoice for on-chain HTLC sweep
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".
2019-01-22 20:46:14 -08:00
Wilmer Paulino
60036aca1d
contractcourt/channel_arbitrator: prevent force closing same channel twice
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.
2018-12-10 20:37:58 -08:00
Olaoluwa Osuntokun
16ec80e163
contractcourt: update tests to use new IncubateOutputs API 2018-09-25 21:49:10 -07:00
Joost Jager
f34ffab9ba
cnct: add channel_arbitor test that exercises the htlcOutgoingContestResolver 2018-09-20 18:17:23 -07:00
Johan T. Halseth
8344b05c38
contractcourt/chanarb test: expand TestChannelArbitratorCommitFailure to coop and local force close 2018-08-23 10:04:43 +02:00
Johan T. Halseth
bb71856204
contractcourt/channel_arbitrator test: add TestChannelArbitratorEmptyResolutions 2018-08-23 00:03:22 +02:00
Johan T. Halseth
53286b8cee
contractcourt test: add TestChannelArbitratorCommitFailure 2018-08-23 00:03:22 +02:00
Johan T. Halseth
1758ad829f
contractcourt/[chain|channel]_arbitrator: define IsPendingClose 2018-08-23 00:03:22 +02:00
Johan T. Halseth
6b24ca0387
contractcourt test: add TestChannelArbitratorPeristence 2018-08-23 00:03:21 +02:00
Johan T. Halseth
75df58c68b
contractcourt: move responsibility for closing force closes to chanArb
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.
2018-08-23 00:03:21 +02:00
Johan T. Halseth
c11e0940c2
contractcourt/channel_arbitrator test: test new coop close actions 2018-08-23 00:03:21 +02:00
Johan T. Halseth
3549f2bc17
contractcourt/[channel|chain]_arbitrator: define MarkChannelClosed 2018-08-22 23:51:04 +02:00
Johan T. Halseth
740db4716f
contractcourt/channel_arbitrator test: test state transitions 2018-08-22 23:51:04 +02:00
Johan T. Halseth
862c7ae223
contractcourt/channel_arbitrator test: check both respChan and errChan
// Both are sent on, so in some cases we would read from errChan first,
making the test fail.
2018-08-22 23:51:04 +02:00
Olaoluwa Osuntokun
c6950fcc2f
contractcourt: update channel arbitrator unit tests due to recent API changes 2018-07-31 21:29:01 -07:00
Olaoluwa Osuntokun
6f60f139f4 multi: switch over import paths from roasbeef/* to btcsuite/* 2018-07-13 17:05:39 -07:00
Johan T. Halseth
ec93bf581d
contractcourt test: add TestChannelArbitratorLocalForceDoubleSpend
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.
2018-05-14 14:21:06 +02:00
Johan T. Halseth
b2949bd728
contractcourt/channel_arbitrator test: add unit tests
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.
2018-04-25 09:37:25 +02:00
Olaoluwa Osuntokun
d64ffcb6c8
contractcourt: add new ChannelArbitrator struct
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.
2018-01-22 19:19:34 -08:00