This commit addresses some lingering TODO’s which ensure that related
state to a channel is properly deleted by the CloseChannel method.
Previously the values for the respective dust-limits of either side,
the on-disk HTLC’s, and any entries the revocation log for the channel
weren’t being properly deleted.
Additionally, we now modify the checks within the unit tests to ensure
that we can still read the channel from disk w/o running into an error
(thought the slice will be blank), and also the the revocation log is
properly garbage collected.
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 fixes bug that could result in the panicking or crashing of
nodes in the case of an at-funding-time reorganization within the
network. In order to avoid such a case, we now ensure that the
advertised transaction index is within the bounds of the block before
attempting to access it.
Note that this is a temporary patch commit until full advertisement
validation which is implemented in the discovery PR lands in master.
Additionally, better reorg handling during the funding process is being
specified within the spec and will properly be implemented within lnd
at a later date.
This commit fixes a slight scripting related issue as a result of
default policy in Bitcoin Core 0.13.1. With this version of Bitcoin
Core, nodes will now enforce a policy that ensures the first argument
of OP_IF is either an empty vector or a 0x01 value. Our current sent of
functions to generate the witness for the delay clause of the
commitment transaction instead uses a 0x00 value rather than an empty
byte vector.
With this commit we fix the issue by ensuring that we use an empty
vector rather an 0x00 for forcing the commitment delay script pathway.
This commit fixes a prior block propagation race-condition by detecting
and properly processing “premature” announcements. A premature
announcement is one that’s received with an anchored block height which
is beyond our chain tip. Once received, we now store these
announcements in a special map that’s caches them in memory. Once a new
block arrives, we check the map for the existence of any entries,
processing them as normal if so.
This commit modifies the logic of the contract hand-off within the
breachArbiter to ensure that only a single internal closeObserver
goroutine is ever active for a given contract.
This modification cleans up the logs in the case of multiple
reconnections and may possible eliminate some non-deterministic bugs
related to channel force closures.
This commit adds the ability to cancel a channel’s internal
closeObserver goroutine by adding a new public facing Stop method.
Additionally, we now make passing a ChainNotifier interface completely
optional. If the ChainNotifier isn’t passed in as a constructor, then
the closeObserver goroutine will never be launched. This new feature
lets the caller ensure that only a single closeObsever for any given
channels exists.
This commit removes the BlockChainIO interface as a dependency to the
LightningChannel struct as the interface is no longer used within the
operation of the LightningChannel.
This commit fixes a potential panic that could arise when one was
attempting to open a channel with the target peer identified by it’s
peerID and an error occurred. In this case, the nodepubKey pointer
would be nil, resulting in a panic when attempting to propagate the
error.
This commit fixes this bug by using a nil byte slice for the node’s
serialized pubkey in the case that the node was identified according to
ti’s peer ID.
This fixes the bug reproduced in #114. The prevHop map in newRoute may
include many more edges than what is used to produce the final route, and
thus the check prior to building the route could result with incorrect
errors being reported. We move this check to after the number of edges
to be used for the route is deduced.
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 refactors the queueHandler slightly to be more aggressive
when attempting to drain the pending message queue.
With this new logic the queueHandler will now attempt to _completely_
drain the pendingMsgs queue by sending it all to the writeHandler
_before_ attempting to accept new messages from the outside
sub-systems. The previous queueHandler was a bit more passive and would
result in messages sitting the the pendingMessage queue longer than
required.
This commit fixes a panic that can occur on 32-bit systems to the
misalignment of a int64/uint64 that’s used atomically using the atomic
package. To fix this issue, we now move all int64/unit64 variables that
are used atomically to the top of the struct in order to ensure
alignment.
Cleaning up some dead-code, satoshisSent/satoshisReceived have been
removed as they aren’t currently used. Instead those values are
accessed directly from the channel themselves.
This commit elminates a sleep in the testHtlcErrorPropagation test by
instead polling for the existence of our target in a tight loop. This
is a small patch over until we get a “topology client” within the
ChannelRouter. This method is robust and can be applied in future tests
until we get the notification client into the ChannelRouter.
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.
