In this commit, we address the meaning of the inbound parameter to
peerConnected. An inbound connection is defined as a connection
initiated by the peer, rather than ourselves.
We also update the inbound value for the peerConnected calls within
OutboundPeerConnected and InboundPeerConnected to reflect the definition
above.
We remove the internale broadcastMessage method, and instead handle the
mutex handling within BroadcastMessage. This lets us hold the mutex only
when neccessary.
This commit removes the sendToPeer method from the server, and instead
moves the necessary logic into SendToPeer. This let's us make the mutex
acquisition more fine-grained, only holding it while reading from the
peer map. Earlier it was required to be held during the whole call to
sendToPeer, as the method would access the map internally.
This commit synchronizes the in-memory cache with the
on-disk state to ensure the waiting proof store is
externally consistent. Currently, there are scenarios
where the in-memory state is updated, and not reverted
if the write fails. The general fix is to wait to apply
modifications until the write succeeds, and use a
read/write lock to synchronize access with db operations.
In this commit, we add and enforce a min fee rate for commitment
transactions created, and also any updates we propose to the remote
party. It's important to note that this is only a temporary patch, as
nodes can dynamically raise their min fee rate whenever their mempool is
saturated.
Fixes#1330.
In this commit, we fix an existing bug in the new graph query sync
feature. Before this commit, when a block is pruned, we would never
actually delete the update index entries. This is due to the fact that
we would attempt to delete the entries from the update index _after_ we
had already removed the edges from the update index.
We fix this by simply swapping the order: first we delete from the
update index, then we delete the edges themselves. A test ensuring that
the entires are cleared (which failed before this commit), has been
added.
In this commit, we go through the codebase looking for TCP address
assumptions and modifying them to include the recently introduced onion
addresses. This enables us to fully support onion addresses within the
daemon.
In this commit, we update the way we reestablish inbound connections if
we lose connectivity to a node we have an open channel with. Rather than
fetching the node's advertised port, we'll fetch one of their advertised
addresses instead. This ensure that if the remote node is running behind
a proxy, we do not see the proxy's address.
In this commit, we allow the daemon to use the recently introduced Tor
Controller implementation. This will automatically create a v2 onion
service at startup in order to listen for inbound connections over Tor.
Co-Authored-By: Eugene <crypt-iq@users.noreply.github.com>
In this commit, we fix a bug where a fallback SRV lookup would leak
information if `lnd` was set to route connections over Tor. We solve
this by using the network-specific functions rather than the standard
ones found in the `net` package.
In this commit, we now allow connections to onion addresses due to
recently adding support to properly parse them.
Co-Authored-By: Eugene <crypt-iq@users.noreply.github.com>
In this commit, we allow `lnd` to properly parse onion addresses in
order to advertise them to the network when set through the
`--externalip` flag.
Co-Authored-By: Eugene <crypt-iq@users.noreply.github.com>
In this commit, we update the set of Tor flags to use sane defaults when
not specified. We also include some new flags related to the recent
onion services changes. This allows users to easily get set up on Tor by
only specifying the tor.active flag. If needed, the defaults can still
be overridden.
In this commit, we add our inital implementation of a Tor Controller.
This commit includes the ability for the controller to automatically
signal the Tor daemon to create a v2 onion service. This will be
expanded later on to support creating v3 onion services.
Before allowing the controller to interact with the Tor daemon, the
connection must be authenticated first. This commit includes support for
the SAFECOOKIE authentication method as a sane default.
Co-Authored-By: Eugene <crypt-iq@users.noreply.github.com>
In this commit, we fix an issue where connections made through Tor's
SOCKS proxy would result in the remote address being the address of the
proxy itself
We fix this by using an internal proxyConn struct that sets the correct
address at the time of the connection.
In this commit, we clean up the tor package to better follow the
Effective Go guidelines. Most of the changes revolve around naming,
where we'd have things like `torsvc.TorDial`. This was simplified to
`tor.Dial` along with many others.
In this commit, we fix an existing panic bug related to the recently
added routing hints feature. If it's the case that the remote node
didn't send us their edge, then when we go to compare the public keys to
see if they match, we may attempt to deref an nil pointer.
In order to fix this, we'll instead check the edgeInfo, which is
guaranteed to also exist if the channel was found in the database. As a
defensive step, before we go to actually aces the struct, we'll check
that's it's non-nil and proceed if it is nil.
In this commit, we fix an existing deadlock in the
gossiper->server->peer pipeline by ensuring that we're not holding the
syncer mutex while we attempt to have a syncer filter out the rest of
gossip messages.
In this commit, we modify the waiting proof slightly to acept dupliacte
waiting proofs, rather than reject them. Otherwise, it's possible that
the remote node first sends us their half of the waiting proof (before
we do), we write that to disk, then upon restart, we'll try to add it
again, but be rejected by the system.
Fixes#1315.
In this commit, we fix a slight bug in the parsing of encoded short
channel ID's. Before this commit, we would always assume that the remote
peer was sending us the sorted+encoded variant of the short channel
ID's. In the case that they weren't (as there isn't yet a feature bit),
we would assert this check and fail early as atm we don't support any
sort of compression.
We check if the channel is FullySynced instead of comparing the local
and remote commit chain heights, as the heights might not be in sync.
Instead we call FullySynced which recently was modified to use compare
the message indexes instead, which is _should_ really be in sync between
the chains.
The test TestChanSyncOweRevocationAndCommitForceTransition is altered to
ensure the two chains at different heights before the test is started, to
trigger the case that would previously fail to resend the commitment
signature.
This commit changes cancelReservationCtx to gold the resMtx from start
to finish. Earlier it would lock at different times only when accessing
the maps, meaning that other goroutines (I'm looking at you
PeerTerminationWatcher) could come in and grab the context in between
locks, possibly leading to a race.
