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.
This commit modifies the internal workflow for opening or closing a
channel in order to create a path in which RPC clients can receive
updates. Updates are now communicated via channels from the goroutines
spawned by the RPC server to process the request, and the sub-system
within the daemon that actually executes the request.
With this change clients can now receive updates that the request is
pending (final message has been sent to the target client), or that the
request has been completed. Confirmation related updates have not yet
been implemented as that will require some changes to the ChainNotifier
interface.
This commit fixes an omission within the htlcSwitch. With this commit,
a channels bandwidth is now properly updated once an incoming HTLC is
settled.
This also fixes a bug where if a node received a payment, it wouldn’t
be able to then utilize the newly available bandwidth to send further
payments.
This commit integrates BitFury's current routing functionality into lnd. The
primary ochestration point for the routing sub-system in the routingMgr. The
routingMgr manages all persistent and volatile state related to routing within
the network.
Newly opened channels, either when the initiator or responder are inserted into
the routing table once the channel is fully open. Once new links are inserted
the routingMgr can then perform path selection in order to locate an "optimal"
path to a target destination.
This commit optimizes the previous deadlock bug-fix within the peer’s
channelManager which handles driving the LCP state machine with
additional context-specific state.
Rather than forwarding to the HTLC switch within the primary loop which
handles fully locked-in HTLCs, we now launch a distinct goroutine which
is responsible for properly forwarding lock-in HTLC’s to the
htlcSwitch.
This commit *significantly increases* the payment throughput per-core,
per-channel of the daemon.
With this commit updates are properly pipelined respecting the current
revocation window, htlc updates are batched, a timer is checked to push
chain convergence, and htlc update below the batch size are
periodically flushed to the remote chain.
The current pending update timer, trickle timer, and batch size have
been arbitrarily chosen based on my local tests. In the future these
parameters should be chosen to optimize response-time and throughput
after measurements are gathered.
With this commit, calls to htlcSwitch.SendHTLC() are now synchronous,
only returning after the payment has been fully settled. This will
allow one to accurately measure the commitment update speed with the
current state machine implementation which is missing a number of
low-hanging optimizations.
The htlcManager for each channel now keeps a map of cleared HTLC’s
keyed by the index number of the add entry within the state machine’s
HTLC log. This map of HTLC’s will later be used to properly implement
time outs
Additionally, a slight refactoring has been executed w.r.t handling
upstream/downstream messages. This cleans up the main htlcManager loop,
freeing it up for the addition of future logic to properly observe
timeouts as well as, proper batching+trickling of HTLC updates, and a
commitment signature ticker.
With this commitment, the daemon is now able to properly send+redeem
single-hop HTLC’s with another daemon running on the same network.
The htlcManager gains an additional channel which is reads from
receiving updates from either downstream peers, or the rpc server. An
htlcManager is spawned for each active channel with the remote peer. As
a result, the readHandler must now de-multiplex any messages which
update a known channel to the proper htlcManager.
Batching HTLC add updates with a trickle timer has not yet been
implemented, but will be in the near future along with several other
optimizations.
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.
This commit switches the implementation of the open/close channel RPC’s
from a fully blocking synchronous model to one that’s async by default,
allowing callers to add a sync wrapper.
The new proto specs also allow for “updates” for the pending channels
in the form of new confirmations which progress the pending status of
the channel. At this point, only the final open/close updates have been
implemented. Obtaining confirmation notifications requires a bit of
re-working within the current ChainNotifier interface, thus this has
been deferred to a later time.
This commit fixes a bug introduced within a prior commit. The prior
commit failed to drollery reverse the txid string taken in as user
input, therefore in order to properly close a channel, the user needed
to manually reverse the txid themselves.
With this change, `wire.NewShaHashFromStr` is used which properly
reverses the string within the constructor. This allows the string
reported not be directly used to the close an active channel.
This commit also corrects a few logging messages.
This commit adds the necessary plumbing within the server, peer, and
rpcServer to handle opening and cooperatively closing a channel with a
remote peer.
Many new data structures have been added to the peer in order to allow
it to efficiently manage opening+.losing new/existing lightning
channels. Additional documentation has been added to several methods
within the peer struct, with some minor renaming along with way. The
peer has also gained a dedicated goroutine whose job it is to manage
any requests pertaining to opening, or closing any channels with the
remote peer.
The messages have been added to lnrpc define the requests and responses
to channel open+close messages. Additional channel logic has been added
between the rpcServer, peer, and server in order to properly manage the
necessary synchronization.
* With this commit, then initial draft of the peer struct is finished.
Items to still complete include the interaction between the peer and
internal wallet, version handshake, pings, etc.
