This commit introduces the initial implementation of the autopilot
mode. Autopilot is new mode within lnd that enables automatic channel
management. This means that if enabled lnd will attempt to
automatically manage channels according to a set of heuristic defined
within the main configuration for autopilot.Agent instance.
The autopilot.Agent implements a simple closed control loop. It takes
in external signals such as wallet balance updates, new open channel,
and channels that are now closed the updates its internal state. With
each external trigger it will consult the registered
AttachmentHeuristic to decide: if it needs to open any more channels,
and if so how much it should use to open the channels, ultimately
returning a set of recommended AttachmentDirectives. The
autopilot.Agent loop will then take those attempt to establish
connection, and go back in waiting for a new external signal.
With this first implementation the default heuristic is the
ConstrainedPrefAttachment implementation of AttachmentHeuristic. Given
a min and max channel size, a limit on the number of channels, and the
percentage of wallet funds to allocate to channels, it will attempt to
execute a heuristic drive by the Barabási–Albert model model in order
to attempt to drive the global graph towards a scale free topology.
This is commit implements a foundational layer for future simulations,
optimization, and additional heuristics.
This commit fixes a bug which was covered by the recent server
refactoring wherein the grouting would be stuck on the send over the
message channel in the case that the handshake failed. This blockage
would create a deadlock now that the ConnectToPeer method is full
synchronous.
We fix this issue by ensuring the goroutine properly exits.
In addition to improved synchronization between the client
and server, this commit also moves the channel snapshotting
procedure such that it is handled without submitting a query
to the primary select statement. This is primarily done as a
precaution to ensure that no deadlocks occur, has channel
snapshotting has the potential to block restarts.
This commit alters the synchronization patterns used in the server
such that the internal state is protected by a single mutex. Overall,
this simplifies the ability to reason about the behavior and
manipulation of the internal state, which has resolved a few of flakes
related to race conditions that were observed before hand.
Invoking DisconnectPeer is now fully synchronous, and waits until
the provided peer's peerTerminationWatcher has exited before
returning. Currently this is done by tracking the watcher using the
peer's WaitGroup, and locking until the peer has shutdown.
The server's API has also been refactored such that all public methods
are safe for concurrent use. Therefore, other subsystems should be
sure to make use of these endpoints to avoid corrupting the internal
state.
Persists the state of a channel opening process after funding
transaction is confirmed. This tracks the messages sent to
the peer such that the process can be continued in case of a
restart. Also introduces that the receiver side forgets about
channel if funding transaction is not confirmed in 48hrs.
In the "multiple channel creation" test, in some cases the
responder (Bob) was not yet considering the first channel
to be opened (activeReservation still not deleted in
fundingManager) when Alice tried to open the second channel.
This would cause the test to fail. This commit adds a small
sleep before the creation of the second channel, to give
Bob some time to finish the opening process.
This commit updates the integration tests to reflect the reality after
removing code that would always attempt to increment the current update
timestamp by one for each channel announcement. Without connecting
directly to carol, it isn’t guaranteed that Alice will receive that
announcement as Bob would have already processed one for Carol when
their channel was created.
This commit fixes an issue where if a party force closing a channel,
doesn’t have a non-dust balance, nor any outgoing HTLC’s, then the
channel would never be marked as fully closed within the database.
We ensure that this case is addressed, by inserting a checking to
determine if we have any funds to sweep, marking the channel fully
closed on initial commitment transaction confirmation if not.
This commit modifies how the htlcswitch handles close requests.
Previously it could be the case that a new channel was added, but at
the same time a channel was requested to be closed. This would result
in a circular waiting dependency: the peer contacts the switch, who
tries to contact the peer.
We eliminate this possibility by ensuring that the switch handles all
close requests asynchronously. With this, the switch won't block
indefinitely in the scenario described above.
This commit ensures that all references within the chanMsgStreams are
all removed and deleted when the readHandler exits. This ensures that
all objects don’t have extra references, and will properly be garbage
collected.
This commit implements a missing policy within the current ChannelLink
interface. If an HTLC arrives that is too close to the current block
height, then we’ll reject it. As otherwise, it may be possible for us
to lose an on-chain claim if they HTLC expires already or expires
before we’re able to get a commitment transaction in the chain.
As the exit node, we have a grace period that governs out decision. As
an intermediate node, we ensure that the HTLC isn’t close to expiry on
our outgoing link end if we forward it.
This commit makes the routing cache invalidation a bit more aggressive.
We now invalidate the cache on each new block as the routes in the
cache are based on the current block height. Using the cached items may
cause our routes to fail due to them having time locks which have
already expired.
This commit implements some missing functionality, namely before all
time locks were calculated off of a base height of 0 essentially.
That’s incorrect as all time locks within HTLC’s would then be already
expired. We remedy this requesting the latest height when creating a
route to ensure that our time locks are set properly.
This commit adds a bit of a guard to a set of RPC calls. If an RPC call
needs to interact with the server but it hasn’t yet been started. Then
we’ll exit early in order to avoid blocking the call until the server
itself has started.
A recent change to the initialization order of sub-systems within lnd
results in a state where the daemon will wait for the wallet itself to
finish syncing _before_ the server is started. This was interpreted as
a bug by some users, so we’ll make the state of the server more
explicit by returning an error.
This commit adds a new utility method to the server struct itself. This
method will allow callers to query the state of the server in order to
decide if the server has been started or not. This can be useful
elsewhere in the project as we start to decouple the lifetime of
certain sub-systems from others.
Make the fundingmanager send an updated node announcement
each time it opens a new channel. This is to make sure
our node announcement is propagated in the network, since
peers will ignore our node announcements if we haven't
opened any channels yet.
According to BOLT#7, nodes will ignore node announcements
for nodes not found in any previous channel announcements.
This commit makes the discovery service send its known
channels before its known nodes when syncing the channel
graph with a peer.
This commit introduces the requirement specified in BOLT#7,
where we ignore any node announcements for a specific node
if we yet haven't seen any channel announcements where this
node takes part. This is to prevent someone DoS-ing the
network with cheap node announcements. In the router this
is enforced by requiring a call to AddNode(node_id) to
be preceded by an AddEdge(edge_id) call, where node_id is
one of the nodes in edge_id.
Adds a HaveNodeAnnouncement field to the LightningNode
struct, which is used to indicate if we have gotten
all the necessary information to fill the remaining
fields in the struct. If we haven't gotten a node
announcement for this specific node, then we only
know the pubkey, and can only fill that field in
the struct. Still, we should be able to add it to the
channel graph and use it for routes, as long as we
know about channels to this node.
