Commit Graph

136 Commits

Author SHA1 Message Date
Joost Jager
47f9c1c3fd
routing: use routingGraph interface in payment session
Preparation for more test coverage of payment session.

The function findPath now has the call signature of the former
findPathInternal function.
2020-04-09 08:20:37 +02:00
Joost Jager
cb4cd49dc8
routing: map insufficient local bandwidth error to no path
With mpp it isn't possible anymore for findPath to determine that there
isn't enough local bandwidth. The full payment amount isn't known at
that point.

In a follow-up, this payment outcome can be reintroduced on a higher
level (payment lifecycle).
2020-04-09 08:20:35 +02:00
Joost Jager
5de308c4b5
routerrpc: update final cltv delta default
The default was increased for the main sendpayment RPC in commit
d3fa9767a9729756bab9b4a1121344b265410b1a. This commit sets the
same default for QueryRoutes, routerrpc.SendPayment and
router.EstimateRouteFee.
2020-01-14 21:03:24 +01:00
Joost Jager
81bf6e15b3
routing+lnrpc: add missing query routes parameters 2020-01-14 11:21:31 +01:00
Conner Fromknecht
32284ef1f1
routing/pathfind_test: use ctx in recent tests
Modifies TestMissingFeatureDep and TestDestPaymentAddr to use the test
ctx directly instead of generating a closure and using local state to
modify restrictions.
2020-01-09 13:53:45 -08:00
Conner Fromknecht
c7a241fc59
routing/pathfind: ignore unknown required features
This commit brings us inline with recent modifications to the spec, that
say we shouldn't pay nodes whose feature vectors signal unknown required
features, and also that we shouldn't route through nodes signaling
unknown required features.

Currently we assert that invoices don't have such features during
decoding, but now that users can specify feature vectors via the rpc
interface, it makes sense to perform this check deeper in call stack.
This will also allow us to remove the check from decoding entirely,
making decodepayreq more useful for debugging.
2020-01-08 12:25:00 -08:00
Wilmer Paulino
9216ef2cd7
Merge pull request #3855 from cfromknecht/sorted-policies
routing/pathfind_test: construct sorted edge policies
2019-12-20 10:27:28 -08:00
Joost Jager
b760b25229
routing: limit routing info size during pathfinding
Also the max hop count check can be removed, because the real bound is
the payload size. By moving the check inside the search loop, we now
also backtrack when we hit the limit.
2019-12-20 11:00:05 +01:00
Joost Jager
513341516e
routing: fix max route length test
Enable the test again and use a programmatically built network.
2019-12-20 11:00:03 +01:00
Joost Jager
72a6383975
routing: use absolute final expiry in pathfinding 2019-12-20 11:00:00 +01:00
Joost Jager
95ddab57fa
channeldb: add tx argument for FetchLightningNode
To allow execution within an existing tx.
2019-12-20 10:17:01 +01:00
Conner Fromknecht
ff443a389b
routing/pathfind_test: constructed sorted edge policies
This commit fixes a potential bug in our test harness, by ensuring that
the constructed node policies are configured _after_ sorting. Currently
the node pubkeys are sorted, but additional parameters (max htlc,
disabled, etc) are applied using the unsorted policies.

Most of the constructors used today use the symmetric channel
constructor, so this shouldn't cause an issue with the majority of our
tests. We recently introduced an asymmetric channel constructor for
which this could have been an issue, however, no known issues were
discovered.

Lastly, we remove the direction from the configuration altogether, and
derive it purely from the final sorting of the pubkeys.
2019-12-19 03:47:24 -08:00
Joost Jager
37d9ee302c
channeldb: take serialized key to fetch lightning node
This prevents inefficient key conversions in a follow up commit that
change the inner pathfinding loop.
2019-12-19 12:44:00 +01:00
Conner Fromknecht
0993256b77
routing/pathfind: set single-shot MPP if payment addr is known 2019-12-18 23:56:42 -08:00
Conner Fromknecht
cddb71ee53
routing/pathfind: evaluate TLV support sooner
We move up the check for TLV support, since we will later use it to
determine if we can use dependent features, e.g. TLV records and payment
addresses.
2019-12-18 23:56:05 -08:00
Conner Fromknecht
495ae8ca42
routing: consolidate final hop params for newRoute
This commit creates a wrapper struct, grouping all parameters that
influence the final hop during route construction. This is a preliminary
step for passing in the receiver's invoice feature bits, which will be
used to select an appropriate payment or payload type.
2019-12-18 23:55:08 -08:00
Conner Fromknecht
71e05e05bf
routing/pathfind: set final hop features used in pathfinding
In this commit, we overwrite the final hop's features with either the
destination features or those loaded from the graph fallback. This
ensures that the same features used in pathfinding will be provided to
route construction.

In an earlier commit, we validated the final hop's transitive feature
dependencies, so we also add validation to non-final nodes.
2019-12-18 23:54:49 -08:00
Conner Fromknecht
990d55d08c
routing/pathfind: ensure final hop supports payment addrs
This commit adds an optional PaymentAddr field to the RestrictParams, so
that we can verify the final hop can support it before doing an
expensive round of pathfindig.
2019-12-18 23:54:31 -08:00
Conner Fromknecht
acb7b83ead
routing/pathfind: validate final hop feature dependencies 2019-12-18 23:54:11 -08:00
Conner Fromknecht
cfa3fe2921
routing/pathfind: fix TLV fallback for unadvertised hops
In this commit, we fix a bug that prevents us from sending custom
records to nodes that aren't in the graph. Previously we would simply
fail if we were unable to retrieve the node's features.

To remedy, we add the option of supplying the destination's feature bits
into path finding. If present, we will use them directly without
consulting the graph, resolving the original issue. Instead, we will
only consult the graph as a fallback, which will still fail if the node
doesn't exist since the TLV features won't be populated in the empty
feature vector.

Furthermore, this also permits us to provide "virtual features" into the
pathfinding logic, where we make assumptions about what the receiver
supports even if the feature vector isn't actually taken from an
invoice. This can useful in cases like keysend, where we don't have an
invoice, but we can still attempt the payment if we assume the receiver
supports TLV.
2019-12-18 23:53:51 -08:00
Conner Fromknecht
bd66c0d34e
routing/pathfind_test: allow custom node features
This commit allows custom node features to be populated in specific test
instances. For consistency, we auto-populate an empty feature vector for
nodes that have nil feature vectors before writing them to the database.
2019-12-18 23:53:32 -08:00
Conner Fromknecht
618810394c
routing/pathfind_test: add asymmetric chan consructor
Later this will be used to populate distinct feature vectors for either
end of the channel.
2019-12-18 23:53:18 -08:00
Joost Jager
883f9e5f9a
Merge pull request #3749 from joostjager/extended-routing-failures
routing: local balance check before path finding
2019-12-04 12:17:17 +01:00
Joost Jager
97344af8f3
routing: local balance check 2019-12-04 09:45:07 +01:00
Joost Jager
3aaf32dc2e
routing: improve equal cost route comparison
When the (virtual) payment attempt cost is set to zero, probabilities
are no longer a factor in determining the best route. In case of routes
with equal costs, we'd just go with the first one found. This commit
refines this behavior by picking the route with the highest probability.
So even though probability doesn't affect the route cost, it is still
used as a tie breaker.
2019-12-02 14:23:57 +01:00
Joost Jager
ac2df9bbf4
routing: use simple errors for path finding 2019-11-27 15:21:08 +01:00
Joost Jager
7e4f9dd70a
routing/test: simplify context instantiation 2019-11-26 21:40:30 +01:00
Joost Jager
f8e9efbf99
routing: allow route to self 2019-11-26 10:15:44 +01:00
Joost Jager
2b332893b7
routing/test: add test focusing on not having a cycle 2019-11-26 10:15:38 +01:00
Joost Jager
814dbea745
routing: add last hop restriction 2019-11-18 21:03:01 +01:00
Joost Jager
0f6af2ed54
routing/test: fix outgoing restriction test
Previously both paths were equal cost, so it could also be a
coincedence that the path with the outgoing restriction would be chosen.
2019-11-18 12:09:43 +01:00
Joost Jager
5fde7977f4
routing/test: create path finding test context 2019-11-18 10:55:43 +01:00
Wilmer Paulino
0fc401de19
routing+routerrpc: take max cltv limit into account within path finding
With the introduction of the max CLTV limit parameter, nodes are able to
reject HTLCs that exceed it. This should also be applied to path
finding, otherwise HTLCs crafted by the same node that exceed it never
left the switch. This wasn't a big deal since the previous max CLTV
limit was ~5000 blocks. Once it was lowered to 1008, the issue became
more apparent. Therefore, all of our path finding attempts now have a
restriction of said limit in in order to properly carry out HTLCs to the
network.
2019-10-11 18:04:49 -04:00
Lars Lehtonen
3b29ecb921 routing: Fix dropped errors in tests.
lnd: Fix dropped errors in tests.

contractcourt: Fix dropped errors in tests.

htlcswitch: Fix dropped errors in tests.

invoices: Fix dropped error in tests.

lnwallet: Fix dropped errors in tests.

macaroons: Fix dropped error in tests.
2019-09-13 06:28:05 +00:00
Joost Jager
3d7de2ad39
multi: remove dead code 2019-09-10 17:21:59 +02:00
Olaoluwa Osuntokun
4697cfde30
routing: extend path finding to be TLV-EOB aware, allow dest TLV records
In this commit, we extend the path finding to be able to recognize when
a node needs the new TLV format, or the legacy format based on the
feature bits they expose. We also extend the `LightningPayment` struct
to allow the caller to specify an arbitrary set of TLV records which can
be used for a number of use-cases including various variants of
spontaneous payments.
2019-08-22 18:53:01 -07:00
Joost Jager
f1769c8c8c
routing: convert to node pair based
Previously mission control tracked failures on a per node, per channel basis.
This commit changes this to tracking on the level of directed node pairs. The goal
of moving to this coarser-grained level is to reduce the number of required
payment attempts without compromising payment reliability.
2019-08-13 19:21:37 +02:00
Olaoluwa Osuntokun
8c389d13f9
Merge pull request #3197 from breez/optimize_prune_zombie_channels
Optimize prune zombie channels
2019-07-18 20:56:56 -07:00
Joost Jager
34b264a3d8
routing: create PathFindingConfig for global parameters 2019-07-18 15:49:25 +02:00
Roei Erez
9781ea0082 router: Optimize pruneZombieChannels.
The current approach iterates all channels in the graph in order to
filter those in need. This approach is time consuming, several seconds
on my mobile device for ~40,000 channels, while during this time the
db is locked in a transaction.

The proposed change is to use an existing functionality that utilize the
fact that channel update are saved indexed by date. This method enables
us to go over only a small subset of the channels, only those that
were updated before the "channel expiry" time and further filter
them for our need.
The same graph that took several seconds to prune was pruned, after
the change, in several milliseconds.

In addition for testing purposes I added Initiator field to the
testChannel structure to reflect the channeldEdgePolicy direction.
2019-07-16 17:48:07 +03:00
Joost Jager
569f821142
routing/test: allow arbitrary graph source nodes 2019-07-11 10:37:22 +02:00
Joost Jager
7133f37bb8
routing: global probability based mission control
Previously every payment had its own local mission control state which
was in effect only for that payment. In this commit most of the local
state is removed and payments all tap into the global mission control
probability estimator.

Furthermore the decay time of pruned edges and nodes is extended, so
that observations about the network can better benefit future payment
processes.

Last, the probability function is transformed from a binary output to a
gradual curve, allowing for a better trade off between candidate routes.
2019-06-04 10:00:25 +02:00
Joost Jager
3349d517aa
routing: add min probability to path finding
This commit adds a new restriction to pathfinding that allows returning
only routes with a minimum success probability.
2019-06-04 10:00:23 +02:00
Joost Jager
6b70791c2d
routing: use probability source in path finding
This PR replaces the previously used edge and node ignore lists in path
finding by a probability based system. It modifies path finding so that
it not only compares routes on fee and time lock, but also takes route
success probability into account.

Allowing routes to be compared based on success probability is achieved
by introducing a 'virtual' cost of a payment attempt and using that to
translate probability into another cost factor.
2019-06-04 10:00:21 +02:00
Joost Jager
35003bd87c
routing/test: sort nodes for channel graph
This commit ensures that channel endpoints in EdgeInfo are ordered
node1 < node2 to not violate assumptions being made by dependent code.
2019-06-04 10:00:13 +02:00
Joost Jager
7a5bd29a69
lnrpc+routing: remove k shortest path finding 2019-05-07 19:54:06 +02:00
Olaoluwa Osuntokun
bab957382f
router: convert Route.ToHopPayloads() to Route.ToSphinxPath()
In this commit, we update the process that we use to generate a sphinx
packet to send our onion routed HTLC. Due to recent changes in the
`sphinx` package we use, we now need to use a new PaymentPath struct. As
a result, it no longer makes sense to split up the nodes in a route and
their per hop paylods as they're now in the same struct. All tests have
been updated accordingly.
2019-04-30 20:13:32 -07:00
Johan T. Halseth
ee257fd0eb
multi: move Route to sub-pkg routing/route 2019-04-29 14:52:33 +02:00
Wilmer Paulino
f23c3b488e
routing: prune channels with disabled bit set on both edges
In this commit, we add an additional heuristic when running with
AssumeChannelValid. Since AssumeChannelValid being present assumes that
we're not able to quickly determine whether channels are valid, we also
assume that any channels with the disabled bit set on both sides are
considered zombie. This should be relatively safe to do, since the
disabled bits are usually set when the channel is closed on-chain. In
the case that they aren't, we'll have to wait until both edges haven't
had a new update within two weeks to prune them.
2019-04-18 21:57:34 -07:00
Wilmer Paulino
78bdcbb115
routing: prune channels only if both edges are present
We do this to ensure we don't prune too aggressively, as it's possible
that we've only received the channel announcement for a channel, but not
its accompanying channel updates.
2019-04-18 21:57:31 -07:00