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.
This commit fixes a possible panic which can arise within the library
due to poor user-data. We now explicitly check for an empty string,
exiting early if found within the Decode method.
This commit uses protobuf’s jsonpb library rather than the built-in
json/encoding library to print the JSOn representation of the responses
from gRPC. By using this library, we are now able to properly display
any values from the response which are “non-truthy” (0, false, etc).
This commit removes the prior work around to display a prefix of the
node’s public key as a vertex. It turns out that if you quote the
string, the it will escape all characters enclosed. This allows us the
drop the hacky “Z” prefix that we used before.
This commit enhances the peer struct slightly be attempting to measure
the ping time to the remote node based on when we send a ping message
an dhow long it takes for us to receive a pong response.
The current method used to measure RTT is rather rough and could be
make much more accurate via the usage of an EMA/WMA and also via
attempting to measure processing time within the readMessage and
writeMessage functions.
This commit adds a new restriction around funding channels at the
daemon level: lnd nodes will not allow either the initiation or the
acceptance of a channel before the node is fully synced to the best
known chain.
This fixes a class of bug that arises when a new node joins the network
and either attempts to open a channel or has a channel extended to them
before the node is fully synced to the network.
This commit modifies the request handling within the sever’s
queryHandler goroutine to ensure that requests from the ChannelRouter
or other related sub-systems don’t block the main processing loop.
We do this simply by launching a goroutine to handle the dispatch of
the request.
Before this commit there was the possibility of a race occurring
between a call to the “lispers” cli command and the normal operation of
peers being connected and disconnected. With this commit, we now ensure
such a race doesn’t occur by properly acquiring the lock for peersByID
before accessing it.
This commit adds an ability to render the channel graph as returned by
the ‘displaygraph’ command. The rendering of the graph itself is
carried about the by the ‘dot’ command which eventually calls out to
graphviz.
Currently the graph is always saved to the same file in the local
directory, but in a later commit the location of the file will be made
configurable.
Finally, the attributes sent to the ‘dot’ command used to render the
graph are still a bit in flux. The parameters will likely be tuned once
the channel graph on testnet grows a bit more.
This commit reverts a prior commit as it broke the integration tests
based on the assumption that all peers use the default port within the
network. The issue which was attempted to be fixed will be remedied
with a patch to the connmgr that allows a caller to cancel a persistent
connection that has failed.
This commit ensures that we now properly handle and propagate errors
that arise when attempting to create a new channel after the funding
transaction is believed to be confirmed.
A previous edge case would arise when a user attempted to create a new
channel, but their corresponding btcd node wasn’t yet fully synced.
This commit adds new behavior to the ChannelRouter struct: we know
rebroadcast our outgoing channels every 30 minutes. This new behavior
should ensure that both directions of an advertised channel edge are
always propagated though the network, fixing the issue of “ghost” edges
which exist but aren’t advertised.
The previous logging message was broken as that target chanpoint was
being overshadowed by the local variable declaration. The new logging
message will properly print the unknown channel point as well as the
peer who sent the message.
This commit fixes a slight bug in the deamon. Previously we would store
the *net.TCPAddr that we observed when we either connected out to the
peer, or the peer connected to us. When making an outgoing connection
the host+port combination would be correct, but when responding to an
incoming connection, the port assigned after the TCP handshake would be
stored in the database. This would cause many goroutines to repeatedly
fail connections within the connmgr. Atm within the connmgr, it isn’t
possible to cancel requests for failed connection even after we’ve
already established a connection.
This commit fixes that issues by using the default peer port when
attempting to establish outbound connections to our channel peers.
This commit fixes a panic that would arise when the daemon attempts to
query for a channel that doesn’t currently exist. The bug was the
result of a typo which checked for the nil existence of the incorrect
variable.
This commit fixes a slight bug in the storage of the capacity of a
channel. Previously, we were subtracting a the hard coded fee amount
without first casting the integer to a btcutil.Amount which results in
a display/rounding error when the amount is converted to BTC.
This commit fixes a slight bug in the utxoNursery. Previously, if we
forced closed a channel that was solely funded by the other party
without pushing any satoshis, then the utxoNursery would attempt to
sweep a target output even though it didn’t actually exist. This would
result in the creation of a negative value’d output due to the hard
coded fees currently used in several areas.
To fix his, we now ignore any “output” with a value of zero, when
adding new outputs to the kindergarden bucket.
This commit implements the newly added RPC to decode payment requests
passed over the command line or directly via gRPC.
With this tool, users can now examine payment requests they see in the
wild for diagnostic or debugging purposes.
This commit is similar to the prior commit to channeldb: we no longer
assume that _both_ edges of a channel will always be advertised. Such
an assumption resulted in the inability for a node to sync graph state
since we were previously returning an error when _both_ edges weren’t
found within the graph database.
To remedy this bug, we now carefully ensure that if one edge doesn’t
exist, then we still sync the other.
This commit fixes a prior bug in the graph database due to an invalid
assumption that both channel edges would _always_ be advertised. This
assumption is invalid, as it’s up to a node’s policy if the advertise
their direction of the channel.
The fix for this assumption is straight forward: ErrEdgeNotFound is no
longer a critical error, instead a nil pointer will now be passed into
the passed callback function.
This commit adds a soft-limit for the minimum allowed channel size.
Without this limit a user may inadvertently create an invalid or
unspendable output due to the hard coded fees in a few areas of the
codebase.
This is a temporary measure, and will be removed once we add dynamic
fees into the mix.
This commit augments the server’s response to successful SendPayment
commands by also returning the full path taken in order to fulfill the
payment. With this information, the user now obtains more context about
their payment whcih can be useful when debugging, or just exploring the
capabilities of the daemon.
This commit fixes a prior bug in the wallet triggered by the creation
of a channel using the single funder workflow, but pushing exactly
*half* of the channel over to the other side. The prior logic to
determine who the initiator would result in a disagreement over who
created the channel initially. This wouldn’t manifest until the channel
was attempted to be closed cooperatively. As both side disagreed about
who created the channel they would apply the closing fee to different
outputs, thereby creating mismatched closing transaction. The signature
would fail to validate as the closer will create a different
transaction from that of the responder.
This commit fixes the issue by properly detecting who initially created
the channel.
