This test was previously working because we'd mine an extra block to
confirm the coins inside `FundCoinsUnconfirmed` when it's a neutrino
backend, as shown in
https://github.com/lightningnetwork/lnd/blob/fdd28c8d888792ea8fde3c557ba9f2594e0a6ec8/lntest/harness.go#L1431
Since neutrino has trouble seeing unconfirmed balance, we now send some
coins to the wallet, confirm those, then do a self-transfer so the node
will have unconfirmed outputs to perform the test.
This commit makes sure the sweep requests are received before mining
blocks to trigger the actual sweeping.
In addition, `testFundingExpiryBlocksOnPending` is updated to deal with
the old `channel link not found` issue.
This commit fixes the heuristic we use for identifying the party
that broadcast a Simple Taproot Channel commitment transaction.
Prior to this change we checked if the last script element was an
OP_DROP. However, both the local and remote commitment outputs
have an OP_DROP at the end.
The new approach checks the resolver's SignDescriptor and compares
that key to the keys in the channel's local ChannelConfig. If the
key is the delay key, we know that it is our commitment transaction.
This commit fixes an issue where we did not properly detect and
therefore record the coop close transaction if it used the newer
RBF coop close v2 scheme. This only affects coop closes of
taproot channels today.
This commit is a large refactor that moves over various responsibilities
from the ChannelRouter to the graph.Builder. These include all graph
related tasks such as:
- graph pruning
- validation of new network updates & persisting new updates
- notifying topology update clients of any changes.
This is a large commit but:
- many of the files are purely moved from `routing` to `graph`
- the business logic put in the graph Builder is copied exactly as is
from the ChannelRouter with one exception:
- The ChannelRouter just needs to be able to call the Builder's
`ApplyChannelUpdate` method. So this is now exported and provided to
the ChannelRouter as a config option.
- The trickiest part was just moving over the test code since quite a
bit had to be duplicated.
This is preparation for an upcoming commit that will move over various
responsibilities from the ChannelRouter to the graph Builder. So that
that commit can be a pure code-move commit, the template for the new
sub-system is added up front here.
In preparation for adding a clean Graph DB interface, we create a
version of FetchLightningNode that doesnt allow a caller to provide in a
transaction.
In this commit, we completely remove the Router's dependence on a Graph
source that requires a `kvdb.RTx`. In so doing, we are more prepared for
a future where the Graph source is backed by different DB structure such
as pure SQL.
The two areas affected here are: the ChannelRouter's graph access that
it uses for pathfinding. And the SessionSource's graph access that it
uses for payments.
The ChannelRouter gets given a Graph and the SessionSource is given a
GraphSessionFactory which it can use to create a new session. Behind the
scenes, this will acquire a kvdb.RTx that will be used for calls to the
Graph's `ForEachNodeChannel` method.
In preparation for structs outside of the `routing` package implementing
this interface, export `routingGraph` and rename it to `Graph` so as to
avoid stuttering.
In this commit, we further reduce the routingGraph interface and this
time we make it more node-agnostic so that it can be backed by any graph
and not one with a concept of "sourceNode".
yyforyongyu