This commit introduces the chanacceptor package which is used
to determine, by a set of heuristics, which open channel messages
to accept and reject. Currently, two acceptors are implemented
via the ChannelAcceptor interface: ChainedAcceptor and RPCAcceptor.
The RPCAcceptor allows the RPC client to respond to the open channel
request, and the ChainedAcceptor allows a conjunction of acceptors
to be used.
We add a wait predicate to make sure the node's on-chain balance is
restored before continuing the restore test case.
This is needed since the DLP test scenario includes several restarts of
the node, and if the node isn't done scanning for on-chain balance
before the restart happens, it would be unlocked without a recovery
window, causing funds to be left undiscovered.
Earlier this delay was needed to increase the likelihood that the DLP
scanario was successfully completed. Since we would risk the connection
being torn down, and the link exit, we could end up with the remote
marking the channel borked, but not finishing the force close.
With the previous set of commits, we should now trigger the force close
before we merk the channel borked, which should ensure we'll resume the
orocess on next restart/connect.
Before publishing the close tx to the network and commit to the
StateCommitmentBroadcasted state, we mark the commitment as broadcasted
and store it to the db. This ensures it will get re-published on startup
if we go down.
Instead of marking the channel Borked in cases where we want to force
close it, we immediately let the peer fail the link. The channel state
will instead be updated by the channel arbitrator, which will transition
to StateBroadcastCommit, marking the channel borked, then marking the
commitment tx broadcasted right before publishing the force close tx. We
do this to avoid the case where we would mark it Borked, but go down
before being able to publish the closing tx.
Storing the force close tx ensures it will be re-published on startup.
Instead of marking the database state when processing the channel
reestablishment message, we wait for the result of this processing to
arrive in the link, and mark it accordingly in the database here.
We do this move the logic determining whether we should force close the
channel or not, and what state to mark it in the DB, to the same place,
as these need to be consistent.
This commit converts the ErrCommitSyncLocalDataLoss error into a struct,
that also holds the received last unrevoked commit point from the remote
party.
TestChainArbitratorRepulishCommitment testst that the chain arbitrator
will republish closing transactions for channels marked
CommitementBroadcast in the database at startup.
When loading active channels for a connected peer, we gather channel
sync messages for all borked channels, and send them to the peer. This
should help a peer realize that the state is irreconcible, as we have
already realized.
Checks that we get ErrDoubleSpend as expected when publishing a
conflicting mempool transaction with the same fee as the existing one,
and that we can publish a replacement with a higher fee successfully.
error
Since btcwallet will return typed errors now, we can simplify the
matching logic in order to return ErrDoubleSpend.
In case a transaction cannot be published since it did not satisfy the
requirements for a valid replacement, return ErrDoubleSpend to indicate
it was not propagated.
This commit fixes a potential issue within the fundingmanager, where
failing to write the channel opening state could cause the channel being
marked open in the DB, but the opening state not being set. On startup
this would cause the channel state machine to not be able to resume.
We fix this by saving the channel opening state _first_. This works
because saving the opening state is idempotent, and in case a channel is
found pending at startup, it will re-register for confirmation
notifications and re-do the process.
Since the advanceFundingState now can handle pending channels, we'll
call it for both pending and non-pending channels, just making sure that
we re-initialize the channel barriers and re-publish the funding tx fro
pending channels.
This commit makes advanceFundingState check whether a channel is still
pending before checking the channel opening state. This lets us call it
directly, without checking whether a channel has confirmed first.
This commit makes the waitForFundingTimeout method synchronous, and
return ErrConfirmationTimeout in case the timeout is reached.
We also simplify the internals by using waitForTimout defined earlier.
This commit defines a new method waitForTimeout, that will be used to
listen for channels timing out. It handles a subset of what is already
handled by waitForFundingWithTimeout, but we want to break that one up
in smaller parts, and waitForTimeout is the first of these.
Since waitForFundingConfirmation is always called in a goroutine, we
make this explicit by requireing the caller to always increment the
waitgroup before calling it.
Similarly to what we did in the previous commit, we move the
responsibility of marking the channel open by calling
handleFundingConfirmation out from waitForFundingWithTimeout to the
caller.
This commit moves the handling of a funding confirmation out of
waitForFundingConfirmation, and instead let the caller handle marking
the channel opened.
This commit moves the opening logic found within
waitForFundingConfirmation into a new method handleFundingConfirmation.
This will make it easier to later break up waitForFundingConfirmation,
and avoid code duplication.
This commit removes the handleFundingConfirmation method, and instead
hands the newly confirmed channel of to advanceFundingState, which will
take the channel through the rest of the channel opening flow.
