Commit Graph

5 Commits

Author SHA1 Message Date
practicalswift a93736d21e multi: comprehensive typo fixes across all packages 2018-02-06 19:11:11 -08:00
Olaoluwa Osuntokun d4e650c85d
peer: the chancloser no longer needs to notify the breach arb of settled transactions 2018-01-22 19:19:59 -08:00
Olaoluwa Osuntokun 3ec83cc82f
peer+contractcourt: delegate watching for co-op closes to the chainWatcher
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.
2018-01-22 19:19:53 -08:00
Olaoluwa Osuntokun b11461fba7
chancloser: report proper final local balance in ChannelCloseSummary
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.
2018-01-08 19:50:21 -08:00
Olaoluwa Osuntokun 050500388c
chancloser: add new state machine to handle details of cooperative channel closure
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.
2017-11-23 23:10:08 -06:00