In this commit we add the set of local features advertised as a
parameter to the newPeer function. With this change, the server will be
able to programmatically determine _which_ bits should be set on a
connection basis, rather than re-using the same global set of bits for
each peer.
This commit adds a new field to the switch’s Config, namely the public
key of the backing lightning node. This field will soon be used to
return more detailed errors messages back to the ChannelRouter itself.
This reverts commit 6db90ef09ab974df0ff09aeaf75a3d80414d4f50.
The root cause was fixed by commit
f4e7c36c80e8e2be9edb78b3b317c69d28d6d78f. As a result, this commit is no
longer needed.
This reverts commit b7704e2de3dc96a4aebc2f47908a8f9def1da7f6.
The root issue was fixed by commit
f4e7c36c80e8e2be9edb78b3b317c69d28d6d78f. As a result, this commit is no
longer needed.
This commit removes another case of unnecessary blockage, by modifying
the sendToPeer method to be fully asynchronous. From the PoV of the
callers that utilize this method currently, there’s no reason to block
until the completion of this method. Additionally, as the graph grows
larger without more intelligent the number of messages sent during
initial dump will start to be prohibitive to waiting for full
completion before proceeding.
In this commit, we make the BroadcastMessage method on the server more
asynchronous by abandoning the two wait groups that it used for
synchronization. It has been observed that a circular waiting loop
between the AuthenticatedGossiper and a peer’s readHandler can cause
the system to dead lock.
By removing this unnecessary synchronization, we avoid the deadlock
case and allow the gossiper itself to no longer block in this scenario.
In this commit we modify the main loop within the peerBootstrapper
slightly to check for a sufficient amount of connections, _before_
checking to see if we need to back off the main loop. With this, we
avoid unnecessarily backing off unless an actual error occurs.
This commit implements 2-week zombie channel pruning. This means that
every GraphPruneInterval (currently set to one hour), we’ll scan the
channel graph, marking any channels which haven’t had *both* edges
updated in 2 weeks as a “zombie”. During the second pass, all “zombie”
channel are removed from the channel graph all together.
Adding this functionality means we’ll ensure that we maintain a
“healthy” network view, which will cut down on the number of failed
HTLC routing attempts, and also reflect an active portion of the graph.
This commit fixes an incorrect logging statement within the
peerBootstrapper goroutine. We we’re using a Debug method previously
when we should’ve been using Debugf in order to properly pass the
logging statement through.
This commit adds a listener queue for each peer, that can be used
to queue listeners that will be notified when the targetted peer
eventually comes online.
This commit adds a new primary goroutine to the server struct:
peerBootstrapper. If peer boostrapping isn’t disabled in the config,
this new goroutine will be launched to attempt to establish a set of
initial connections for a new node. The logic is pretty straight
forward: first a set of initial connections is attempted, if after our
first epoch, we don’t have enough connections yet, then we’ll attempt
to query for an additional set. In each iteration, if we haven’t been
successful, then we increase our exponential backoff in order to not
spam any of our bootstrapping sources.
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.
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.
This commit updates the main single-funder funding workflow within the
fundingManager (initiated via the rpcserver or by a message from a
connected peer) to fully adhere to the funding protocol outlined in
BOLT-0002.
The major changes are as follows:
* All messages modified to use the new funding messages in BOLT-0002.
* The initiator of a funding workflow no longer decides how many
confirmations must elapse before the channel can be considered open.
* Rather than each side specifying their desired CSV delay, both
sides now specify the CSV delay for the _other_ party.
In previous commits we have intoduced the onion errors. Some of this
errors include lnwire.ChannelUpdate message. In order to change
topology accordingly to the received error, from nodes where failure
have occured, we have to propogate the update to the router subsystem.
In this commit daemon have been changed to set the proper hooks in the
channel link and switch subsystems so that they could send and receive
encrypted onion errors.
This commit overhauls the way that lnd is created with the goal of
ensuring the chain backends are fully synced up before the daemon
itself starts. The rpcServer has been slightly decoupled from the
server itself s.t we can start the rpcServer independently of the
server. This is required as we’ll now wait (unless we’re in simnet
mode) for the chain to fully sync up before we even _start_ any of the
server’s goroutines.
This commit modifies the Peers method on the server such that a caller
is able to query this method without the main serger goroutines
started. This is a small component in a larger change which will let us
start the RPC server independently of the server.
In current commit big shift have been made in direction of unit testable
payments scenarios. Previosly two additional structures have been added
which had been spreaded in the lnd package before, and now we apply
them in the lnd itself:
1. ChannelLink - is an interface which represents the subsystem for
managing the incoming htlc requests, applying the changes to the
channel, and also propagating/forwarding it to htlc switch.
2. Switch - is a central messaging bus for all incoming/outgoing htlc's.
The goal of the switch is forward the incoming/outgoing htlc messages
from one channel to another, and also propagate the settle/fail htlc
messages back to original requester.
With this abtractions the folowing schema becomes nearly complete:
abstraction
^
|
| - - - - - - - - - - - - Lightning - - - - - - - - - - - - -
|
| (Switch) (Switch) (Switch)
| Alice <-- channel link --> Bob <-- channel link --> Carol
|
| - - - - - - - - - - - - - TCP - - - - - - - - - - - - - - -
|
| (Peer) (Peer) (Peer)
| Alice <----- tcp conn --> Bob <---- tcp conn -----> Carol
This commit adds the FeeEstimator interface, which can be used for
future fee calculation implementations. Currently, there is only the
StaticFeeEstimator implementation, which returns the same fee rate for
any transaction.
This commit fixes a bug that was introduced when the connection
handling was re-worked to properly handle the case of concurrent
connections being made. In certain cases after a successful initial
connection, a peer’s stray goroutine would still attempt to establish a
second outbound connection even though a connection had already been
established. This was properly handled by the connecting peer, but not
he receiving peer. This commit adds the additional logic to the
receiving peer to ensure that we properly handle this case.
In this commit waiting proofs array have been replaced with persistant
boltd storage which removes the possibility for the half proof to be
lost during half proof exchange.
This commit modifies the implementation of the new DisconnectPeer RPC
in the following ways:
* all validation has moved from the server to the rpcserver
* rather than iterating over _all_ channels, we now only check the
peer’s channels
* the disconnectPeerMsg now has a public key object
* this allows us to also verify that the user submitted a valid
pub key string
* we now check if a peer was persistent when disconnecting so we can
remove them from the persistent peer map
This commit fixes a prior bug wherein if a user connected to a peer
using the —perm command, then once the peer was disconnected, we
wouldn’t automatically connect to them.
Issue: 139
This commit contains client-side and server-side functionality
for disconnecting peers. rpc-client calls server side method and sends
message with pubKey.
This commit fixes a bug that was introduced when the concurrent
connection handling logic was re-written: if we don’t properly add the
persistent outbound connection to the persistent conn reqs map. The fix
is easy: add the pending conn req to the proper map.
This commit fixes a bug that would possibly result in tens of goroutine
beaching launched in an attempt to persistently connect to a peer. This
bug has been fixed by ensuring that we’ll only launch a new pending
connection attempt if we don’t already have one pending.
The prior methods we employed to handle persistent connections could
result in the following situation: both peers come up, and
_concurrently_ establish connection to each other. With the prior
logic, at this point, both connections would be terminated as each peer
would go to kill the connection of the other peer. In order to resolve
this issue in this commit, we’ve re-written the way we handle
persistent connections.
The eliminate the issue described above, in the case of concurrent peer
connection, we now use a deterministic method to decide _which_
connection should be closed. The following rule governs which
connection should be closed: the connection of the peer with the
“smaller” public key should be closed. With this rule we now avoid the
issue described above.
Additionally, each peer now gains a peerTerminationWatcher which waits
until a peer has been disconnected, and then cleans up all resources
allocated to the peer, notifies relevant sub-systems of its demise, and
finally handles re-connecting to the peer if it's persistent. This
replaces the goroutine that was spawned in the old version of
peer.Disconnect().
This commit re-writes the GetNetworkInfo implenetaiton to use a single
database transaction. We’re now able to do this due to the recent
change in the API for the ChannelGraph struct and it’s related objects.
The recent change allows the passed callback to accept a db
transaction, with this, the callback is now able to issue another
traversal routine _within_ the prior one.
This commit modifies the fundingManager config to use the a SignMesage
function rather than two distinct functions for singing one half the
channel announcement proofs. This change unifies the signing of
messages under a single abstraction: the MessageSigner interface.
This commit eliminates a possible deadlock (or repeated peer connection
failures) that can arise due to the [inbound|outbound]PeerConnected
methods holding the peer mutex too long. We now alleviate this
concurrency issue by calling s.peerConnected in an asynchronous manner.
This is safe as all operations within the method are themselves
goroutine-safe.
This commit implements some minor coding style, commenting and naming
clean up after the recent major discovery service was merged into the
codebase.
Highlights of the naming changes:
* fundingManager.SendToDiscovery -> SendAnnouncement
* discovery.Discovery -> discovery.AuthenticatedGossiper
The rest of the changes consist primary of grammar fixes and proper
column wrapping.
Add usage of the 'discovery' package in the lnd, now discovery service
will be handle all lnwire announcement messages and send them to the
remote party.
This commit modifies the logic around the opening p2p handshake to
enforce a strict timeout around the receipt of the responding init
message. Before this commit, it was possible for the daemon and certain
RPC calls to deadlock as if a peer connected, but didn’t respond with
an init msg, then we’d be sitting there waiting for them to respond.
With this commit, we’ll now time out, kill the connection and then
possible attempt to re-connect if the connection was persistent.
Use addresses and ports from NodeAnnouncement messages for reconnection
attempts. For those nodes that don't explicitly report IP addresses, use
the IP address from previous connections connection request along with
the default peer port number.
Minor change to server.go to add ExternalIPs to
channeldb.LightningNode. Also, added a test that utilizes this
functionality and exercises multiple addresses in NodeAnnouncement.
This commit modifies address handling in the NodeAnnouncement struct,
switching from net.TCPAddr to []net.Addr. This enables more flexible
address handling with multiple types and multiple addresses for each
node. This commit addresses the first part of issue #131 .
If an error occurs during, peer initialization then 'p' is nil. This
may cause a panic while accessing the peer's member
variables.
To avoid such panics, we now omit the call to `p.Disconnect`
and also directly access the `connmgr.ConReq` variable if it's
non-nil.
This commit removes all instances of the fastsha256 library and
replaces it with the sha256 library in the standard library. This
change should see a number of performance improvements as the standard
library has highly optimized assembly instructions with use vectorized
instructions as the platform supports.
This commit renames routing processing method in the funding mangers
config from ProcessRoutingMessage to SendToRouter and also modifies the
signature to only require the message itself and not the server’s
identity public key.
When the funding transaction has been confirmed, the FundingLocked
message is sent by the peers to each other so that the existence of the
newly funded channel can be announced to the network.
This commit also removes the SingleFundingOpenProof message.
Once a channel funding process has advanced to the point of broadcasting
the funding transaction, the state of the channel should be persisted
so that the nodes can disconnect or go down without having to wait for the
funding transaction to be confirmed on the blockchain.
Previously, the finalization of the funding process was handled by a
combination of the funding manager, the peer and the wallet, but if
the remote peer is no longer online or no longer connected, this flow
will no longer work. This commit moves all funding steps following
the transaction broadcast into the funding manager, which is available
as long as the daemon is running.
github.com/lightningnetwork/lnd master ✗
0m ◒
▶ golint
htlcswitch.go:292:4: should replace numUpdates += 1 with numUpdates++
htlcswitch.go:554:6: var onionId should be onionID
htlcswitch.go:629:7: var onionId should be onionID
lnd_test.go:133:1: context.Context should be the first parameter of a
function
lnd_test.go:177:1: context.Context should be the first parameter of a
function
networktest.go:84:2: struct field nodeId should be nodeID
peer.go:1704:16: should omit 2nd value from range; this loop is
equivalent to `for invoice := range ...`
rpcserver.go:57:6: func newRpcServer should be newRPCServer
github.com/lightningnetwork/lnd master ✗
9m ⚑ ◒ ⍉
▶ go vet
features.go:12: github.com/lightningnetwork/lnd/lnwire.Feature
composite literal uses unkeyed fields
fundingmanager.go:380: no formatting directive in Errorf call
exit status 1
Previously, during the channel funding process, peers sent wire
messages using peer.queueMsg. By switching to server.sendToPeer, the
fundingManager is more resilient to network connection issues or system
restarts during the funding process. With server.sendToPeer, if a peer
gets disconnected, the daemon can attempt to reconnect and continue the
process using the peer’s public key ID.
This commit prevent unnecessary connection flapping by ensure we don’t
attempt to auto-connect to a peer that we’re unable to create or start
the goroutines of. With this commit, we won’t attempt to auto-connect
to a peer that has incompatible feature sets to that of ours.
In this commit the support for global and local feature vectors were
added in 'server' and 'peer' structures respectively. Also with commit
additional logic was added and now node waits to receive 'init'
lnwire.Message before sending/responding on any other messages.
This commit modifies the existing syncing logic to launch a new
goroutine on connect to synchronize graph state with the new peer
rather than the prior blocking version. This change should make the
initial sync a little snappier and also possible eliminate a circular
dependency between the ChannelRouter and the server.
This commit moves much of the logic for querying for a potential route,
constructing the HTLC including the Sphinx packet, and sending the
ultimate payment from the rpcServer to the ChannelRouter.
This movement paves the way for muilt-path path finding as well as
adding automatic retry logic to the ChannelRouter. Additionally, by
having the ChannelRouter construct the Sphinx packet, we’ll be able to
also include the proper time-lock and general per-hop-payload
information properly in the future.
This commit fixes a goroutine closure bug introduced by a prior commit.
A prior commit launched a goroutine for each peer to broadcast the
messages in parallel. However, as written this caused the messages to
only be broadcast to a single peer. When launching goroutines in a
for-loop, the “range” variable is actually re-used and re-assigned
within each iteration of the for-loop. As a result, all goroutines
launched will bind onto the _same_ instance of the variable.
We fix this bug in this commit by properly binding the target peer to a
new variable within the closure that launches the goroutine.
Relevant sources:
*
https://github.com/golang/go/wiki/CommonMistakes#using-goroutines-on-loo
p-iterator-variables
* https://golang.org/doc/faq#closures_and_goroutines
This commit slightly optimizes the process of broadcasting a message to
a list of peers, and also sending a set of messages to a target peer.
When broadcasting a message to a set of target peers, we now launch a
goroutine for each send as to not block the ChannelRouter on an
individual send. When sending a set of messages to a target peer, we
now give up the mutex as soon as we’ve access the map, rather than
holding onto it until the sending is complete.
