Commit Graph

54 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun 276c384455
breacharbiter: fix double channel close panic bug
This commit fixes s bug in the breachArbiter which was introduced
during the change that added the live channel hand off from an active
peer. Rather than closing the settle channel of the _older_
breachObserver, the settle channel of the newer beachObserver was being
closed. This would result in a panic once the channel itself was
actually settled as the channel would be closed again.

To fix this bug, we now properly close the channel of the old settle
signal instead of the new one.
2016-12-30 16:30:11 -08:00
Olaoluwa Osuntokun 3e1c98f2f7
breacharbiter: accept handoff for live channel on peer connect
This commit modifies the interaction between the breachArbiter and the
peer struct such that the breachArbiter _always_ has the latest version
of a contract.

Prior to this commit once we connected out to a peer which we had an
active contract with and the breachArbiter was watching, we’d have two
copies of the channel in memory, instead of just a single one. This was
wasteful and caused some duplicated log messages due to two instances
of the channel being active.
2016-12-27 16:45:05 -08:00
Olaoluwa Osuntokun 71c6e837e3
breacharbiter: fix bug, don't exit main loop due to unknown contract 2016-11-28 20:08:06 -08:00
Olaoluwa Osuntokun 494fcec874
breacharbiter: introduce new sub-system to watch for breaches
This commit introduces a new sub-system into the daemon whose job it is
to vigilantly watch for any potential channel breaches throughout the
up-time of the daemon. The logic which was moved from the utxoNursery
in a prior commit now resides within the breachArbiter.

Upon start-up the breachArbiter will query the database for all active
channels, launching a goroutine for each channel in order to be able to
take action if a channel breach is detected. The breachArbiter is also
responsible for notifying the htlcSwitch about channel breaches in
order to black-list the breached linked during any multi-hop forwarding
decisions.
2016-11-28 19:44:09 -08:00