This commit removes the inspection of the return error
from broadcastTx. This is done since the new error
checking added to PublishTransaction will return a nil
error in case the transaction already exists in the
mempool.
In this commit, we update the chan closer state machine to be fully
spec compliant. A recent change was made to the spec to enforce a
strict ordering such that, the negotiation is well formed. To enact
this change, we’ll ensure that before the closeFeeNegotiation phase,
the *initiator* is always the one that sends the CloseSigned message
first.
In this commit, we modify the interaction between the chanCloser
sub-system and the chain notifier all together. This fixes a series of
bugs as before this commit, we wouldn’t be able to detect if the remote
party actually broadcasted *any* of the transactions that we signed off
upon. This would be rejected to the user by having a “zombie” channel
close that would never actually be resolved.
Rather than the chanCloser watching for on-chain closes, we’ll now open
up a co-op close context to the chainWatcher (via a layer of
indirection via the ChainArbitrator), and report to it all possible
closes that we’ve signed. The chainWatcher will then be able to launch
a goroutine to properly update the database state once any of the
possible closure transactions confirms.
Prior to this commit, the final close summary we added to the database
for the initiator of the channel was incorrect. This is due to the fact
that before, we would use the final snapshot to determine how many
coins the local party was delivered as a result of the cooperative
closure transaction. This is incorrect, as the local party pays fees on
the closure transaction if it’s the initiator.
To remedy this, we’ll now use the new return value of
CompleteCooperativeClose to properly note our final balance in the
database.
In this commit, we add a new state machine to the project in order to
simplify and encapsulate the logic of negotiating the fees of the
closing transaction during the cooperative channel closure procedure.
This new implementation fixes several defects in the prior version of
the fee negotiation protocol as previously implemented within the peer.
Namely, we’ll now ensure that we converge to an acceptable fee
eventually, and clamp down the fee in the case that the starting fee is
greater than the fee of the commitment transaction.
The new fee negotiation also is very simple and should serve as a good
base for future improvements. After proposing our initial fee, if the
fee proposed by the remote party isn’t within 30% of our last fee, then
we increase/decrease our fee by 10%. This process continues until
either they send the same fee as we sent in a prior round, or they send
the identical fee that we sent in the last round.
