This commit revamps the way in bound and outbound connections are
handled within lnd. Instead of manually managing listening goroutines
and also outbound connections, all the duty is now assigned to the
connmgr, a new btcsuite package.
The connmgr now handles accepting inbound (brontide) connections and
communicates with the server to hand off new connections via a
callback. Additionally, any outbound connection attempt is now made
persistent by default, with the assumption that (for right now),
connections are only to be made to peers we wish to make connections
to. Finally, on start-up we now attempt to connection to all/any of our
direct channel counter parties in order to promote the availability of
our channels to the daemon itself and any RPC users.
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.
This commit introduces the utxoNursery. The duty of the utxoNursery is
to watch over CSV-locked immature outputs until they’ve fully matured.
An output is mature once both its sequence lock indicated by the CSV op
code within its output has become active. Once an output is mature the
nursery sweeps the outputs in batches into the source wallet.
The utxoNursery executes its duties once a commitment transaction has
been broadcast on-chain.
This commit modifies the daemon’s initialization within the `lndMain`
method to create an instance of the current default ChainNotifier
outside of the LightningWallet.
At this point, since there are no other implementations of the
ChainNotifier, the current concrete implementation BtcdNotifier is used
by default. In the future, once other ChainNotifier implementations are
in place, config parsing should be fed into a factory function which
creates the proper ChainNotifier implementation.
Finally, several imports have been updated to reflect the change in
package name.
Each active channel now gains its a dedicated htlcManager goroutine
which currently accepts to two golang channels, and a lightning
channel. The “downstream” channel will be used for dispatched multi-hop
payments sent from the htlcSwitch, while the “upstream” channel will be
used once the readHandler de-multiplexes hltc add/timeout/settle
messages.
Each time a new channel is fully created after N confirmations, the
peer’s channelManager registers the new link with the htlcSwitch. Once
the channel is closed either cooperatively or non-cooperatively, then
the link is unregistered.
