This commit adds a test for an lnd instance experiecing a reorg,
making sure a channel that is in the channel graph (using the
describegraph rpc call) will no longer be after the funding tx
gets reorged out.
This commit adds a test for the FilteredChainView interfaces,
making sure they notify about disconnected/connected blocks
in the correct order during a reorg.
This commit makes use of the blockEventQueue within the neutrino
implementation of FilteredChainView to ensure connected and
disconnected blocks are consumed in order by the reader.
It also specifies that neutrino is not to send disconnected blocks
notifications during rescans, making it consistent with the btcd
implementation.
This commit moves btcd view away from using the deprecated
callbacks onBlockConnected/Disconnected, and instead use
onFilteredBlockConnected/disconnected.
This commit also implements the sending of disconnected blocks
over the staleBlocks channel. To send these blocks, the
blockEventQueue is used to ensure the ordering of blocks are
correctly kept.
It also changes the way filter updates are handled. Since we
now load the tx filter to the rpc server itself, we can call
RescanBlocks instead of manually filtering blocks. These
rescanned blocks are also added to the blockEventQueue,
ensuring the ordering is kept.
blockEventQueue is an ordered queue for block events sent from a
FilteredChainView. The two types of possible block events are
connected/new blocks, and disconencted/stale blocks. The
blockEventQueue keeps the order of these events intact, while
still being non-blocking. This is important in order for the
chainView's call to onFilteredBlockConnected/Disconnected to not
get blocked, and for the consumer of the block events to always
get the events in the correct order.
This commit adds the method DisconnectBlockAtHeight to the channel
graph database, making it possible to "rewind" the database in case
a block is disconnected from the main chain. To accomplish this,
a prune log is introduced, making it possible to keep track of the
point in time where the database was pruned. This is necessary for
the case where lnd might wake up on a stale branch, and must "walk
backwards" on this branch after it finds a common block fro the
graph database and the new main chain.
This commit refactors the core logic of the
chanMsgStream to support an additional stream
that is used to asynchronously queue for in-order
delivery to the authenticated gossiper. The channel
streams are slightly adapted to use the more flexible
primitive. We may look to refactor this using more
isolated interfaces, but for now this provides a
minimal change to resolving known flakes.
In this commit, we modify the assertNumOpenChannelsPending to poll
every 200ms rather than just a single attempt. The goal of this commit
is to reduce the number of flakes on travis caused by slow instances.
In this commit we modify the establishTestConnection() function that
each of the brontide unit tests utilize. Before this commit, we would
fully block on the Accept method of the listener. Since then it has
been observed, that at times if Accept blocks indefinitely, then the
entire test will fail after 10 minutes. To allow the test to return
early with a pertinent error, we’ll now make the entire test async, so
we can immediately return with an error if detected.
In this commit, we add a TCP fallback option for the
DNSSeedBootstrapper. We’ve received many reports of users unable to
bootstrap properly to the network due to the size of the SRV records we
currently return. It has been observed that many revolvers will simply
truncate and ignore the response due to the (current size).
To resolve (no pun intended) we now attempt to detect this failure mode
and will fallback to a manual TCP resolution in the case that our SRV
query over UDP fails. We do this by querying the special record at the
"soa." sub-domain of supporting DNS servers. The retuned IP address
will be the IP address of the authoritative DNS server. Once we have
this IP address, we'll connect manually over TCP to request the SRV
record. This is necessary as the records we return are currently too
large for a class of resolvers, causing them to be filtered out.
In this commit we modify the ConstrainedPrefAttachment.Select method to
first shuffle the set of potential candidates before selecting them.
This serves to remove the existing grouping between candidates which
may have influenced the selection.
In this commit we restore the prior workflow of the docker-compose set
up with have to allow developers to quickly erect an lnd+btcd instance.
In a recent change, we now prompt the user for a passphrase that will
be used to encrypt the wallet database. This affected the prior
workflow, as it assumed set up was non-interactive.
In this commit we restore the prior behavior as we now start the lnd
nodes with --noencryptwallet.
This commit decouples the wait for funding transaction confirmations
in the waitForFundingConfirmation function from the announcement of
the channel in the sendFundingLockedAndAnnounceChannel function.
Additionally, the sendFundingLockedAndAnnounceChannel function is
now decoupled into the sendFundingLocked and sendChannelAnnouncement
functions. There is also now a helper function that houses creation
of a lnwire.LightningChannel object, calls to both sendFundingLocked
and sendChannelAnnouncement.
This commit refactors the SynchronizeNode logic such that
it can be called without interacting with the gossiper's
main execution loop. This method does not require access
to any of the gossiper's internal state, making the change
fairly straightforward. The primary motivation behind
this change is to minimize the possibility of introducing
deadlock scenarios between the gossiper and server.
This commit make the fundingmanager tests poll for database state
for a time, instead of using an explicit sleep before accessing the
DB. This should address some of the flakes encountered on Travis,
where db writes might take longer than usual.
In this commit, we extend the testMultiHopPayments test case to add an
additional node to the multi-hop payment route: Dave.
Related to #391 as it uses the provided code fragment to reproduce the
bug. With this test in place, we’ll now be able to notice any
regressions in this area.
In this commit, we address a lingering TODO within the
TestUpdateForwardingPolicy test case to ensure that Bob will reject the
payment the second time around due to an update in his fee policy.
Before this commit, we would expect that structurally we don’t pay any
fee for the first hop, but do for the final hop. After the latest
commit, this is now flipped as when we say fee, we mean the fee that we
need to pay to transit a link. For the final hop, there’s no additional
distance to be traveled, so the fee is nothing.
In this commit we fix an existing miscalculation in the fees that we
prescribe within the onion payloads for multi-hop routes. Before this
commit, if a route had more than 3 hops, then we would erroneously give
the second to last hop zero fees.
In this commit we correct this behavior, and also re-write the fee
calculation code fragment within newRoute for readability and clarity.
There are now only two cases: this is the last hop, and this is any
other hop. In the case of the last hop, simply send the exact amount
with no additional fee. In the case of an intermediate hop, we use the
_prior_ (closer to the destination) hop to calculate the amount of fees
we need, which allows us to compute the incoming flow. Using that
incoming flow, we then can compute the amount that the hop should
forward out.
Partially fixes#391.
In this commit we fix a slight bug within the existing SendPayment loop
which would cause the wrong error to be returned to users. Prior to
this commit, if we received an update identical to what we were already
aware of, then that error would be returned rather than the
ForwardingError that encapsulated this update.
In this commit with remedy this by properly returning the exact error.
Partially fixes#391.
In this commit we modify all the test that involve sending payments to
use the payreq returned rather than manually populating the
payhash+dest fields in the SendRequest proto argument to SendPayment.
This is required as if we don’t use the payreq returned, then the
receiving node will reject the payment as it’ll use the global final
CLTV delta value, rather than the value (within the pay req) that the
receiver is expecting.
In this commit we restore the in memory ChannelRouter as we’ll no
dynamically set the ChannelRouter’s pointer within he spec path finding
test example.
In this commit, we fix an existing derivation from the commitment state
machine as defined within the specification. Before this commit, we
only kept a single counter which both HTLC adds and fails/settles would
share. This was valid in the prior pre-spec iteration of the state
machine. However in the current draft of the spec, only a distinct
counter for HTLCs are used throughout.
This would cause an incompatibility, as if we mixed adds and settles
during an exchange, then our counter values would differ with other
implementations. To remedy this, we now introduce a distinct HTLC
counter and index within the updateLog.
Each Add will increment both the log counter, and the HTLC counter.
Each Settle/Fail will only increment the log counter. Inbound
Settle/Fails will index into the HTLC index as to target the proper
HTLC. The PaymentDescriptor type has been extended with an additional
field (HltcIndex) which itself tracks the index of an incoming/outgoing
HTLC.
