Commit Graph

54 Commits

Author SHA1 Message Date
eugene
a70d0bef34
multi: validate payment params at RPC layer
With this patch, we'll fail out earlier in the cycle in case of
some wonky parameters, and not leave zombie payments in the router
which currently are not cleaned up.
2021-05-13 17:17:52 -04:00
Conner Fromknecht
8c404ade18
routing: allow splitting for AMP or MPP 2021-05-10 22:02:14 -07:00
Johan T. Halseth
f07c9d002c
routing: use Identifier in place of PaymentHash
Since we want to support AMP payment using a different unique payment
identifier (AMP payments don't go to one specific hash), we change the
nomenclature to be Identifier instead of PaymentHash.
2021-04-27 09:47:23 +02:00
yyforyongyu
541fbbb054
routing: check payment.DestFeatures against nil 2021-03-17 00:14:20 +08:00
Olaoluwa Osuntokun
b73a6e2c61
routing: if MaxShardAmt is set, then use that as a ceiling for our splits
In this commit, we thread through the necessary state to allow users to
set a max shard amount. If this value is set, then this'll effectively
serve as a ceiling for all our split attempts. If we need to split,
we'll first try to use `paymentAmt/2`, if that's bigger than
`MaxShardAmt, then we'll use the latter instead.

Ideally in the future we have a dynamic way to automatically set both
the `MaxShardAmt` as well as `MaxParts` for users. Until then exposing
these two new fields will allow us to experiment with setting them
automatically using the RPC interface, and also give users a bit more
control over how we attempt to route payments, akin to coin control for
on-chain payments.

Fixes #4730
2021-02-15 19:31:52 -08:00
Juan Pablo Civile
f574c150aa routing: limit max parts if the invoice doesn't declare MPP support 2021-01-15 14:56:32 -03:00
Joost Jager
3ef68baf4a
routing: don't treat bad features as an unexpected error
Previous behavior led to the payment loop being abandoned immediately,
resulting in a payment stuck in state in_flight.
2020-05-27 12:15:53 +02:00
Joost Jager
c33d94ff27
routing+routerrpc: add multiple outgoing channel restriction 2020-05-12 07:17:24 +02:00
Joost Jager
f6b2410011
routing+routerrpc: rename max_shards to max_parts
Don't introduce a new term and align with the P in MPP.
2020-04-22 14:49:19 +02:00
Joost Jager
7fc1938f10
routing: payment splitting pre-check
This commit reverts cb4cd49dc8d3b0255afe9ff29af9c46c2dbb2c98 to bring
back the insufficient local balance failure.

Distinguishing betweeen this failure and a regular "no route" failure
prevents meaningless htlcs from being sent out.
2020-04-18 08:30:26 +02:00
Joost Jager
805641adf5
routing: do not split payment if destination does not support mpp 2020-04-17 14:23:57 +02:00
Joost Jager
9bd7eb74b6
routing: add prefix logger for payment session 2020-04-17 14:23:55 +02:00
Joost Jager
6e8442b333
routing: move payment session constructor 2020-04-16 16:25:24 +02:00
Joost Jager
969eecc7d2
routing+routerrpc+lncli: rename MaxHtlcs to MaxShards 2020-04-14 10:31:59 +02:00
Joost Jager
e9bd691e6a
routerrpc+routing: adapt payment session for multi shard send
Modifies the payment session to launch additional pathfinding attempts
for lower amounts. If a single shot payment isn't possible, the goal is
to try to complete the payment using multiple htlcs. In previous
commits, the payment lifecycle has been prepared to deal with
partial-amount routes returned from the payment session. It will query
for additional shards if needed.

Additionally a new rpc payment parameter is added that controls the
maximum number of shards that will be used for the payment.
2020-04-09 08:20:49 +02:00
Joost Jager
46f5fc7400
routing: distinguish between receiver amount and total amount in newRoute 2020-04-09 08:20:47 +02:00
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
Johan T. Halseth
5e72a4b77c
routing: exit on unexpected RequestRoute error
We whitelist a set of "expected" errors that can be returned from
RequestRoute, by converting them into a new type noRouteError. For any
other error returned by RequestRoute, we'll now exit immediately.
2020-04-02 19:31:24 +02:00
Johan T. Halseth
49efbefb43
routing/payment_session: remove prebuilt payment session
Since we no longer use payment sessions for send to route, we remove the
prebuilt one.
2020-04-02 10:24:35 +02:00
Johan T. Halseth
00903ef9f5
routing/payment_session: make RequestRoute take max amt, fee limit and
active shards

In preparation for doing pathfinding for routes sending a value less
than the total payment amount, we let the payment session take the max
amount to send and the fee limit as arguments to RequestRoute.
2020-04-02 10:24:33 +02:00
Johan T. Halseth
c2301c14b2
routing/payment_session: make NewPaymentSession take payment directly
This commit moves supplying of the information in the LightningPayment
to the initialization of the paymentSession, away from every call to
RequestRoute.

Instead the paymentSession will store this information internally, as it
doesn't change between payment attempts.

This is done to rid the RequestRoute call of the LightingPayment
argument, as for SendToRoute calls, it is not needed to supply the next
route.
2020-04-02 10:24:33 +02:00
Joost Jager
72a6383975
routing: use absolute final expiry in pathfinding 2019-12-20 11:00:00 +01:00
Conner Fromknecht
f868bc128b
rpcserver+routerrpc: thread features + payment addr to SendPayment 2019-12-18 23:56:59 -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
Joost Jager
75aa4e7061
routing: require tlv capability for custom record payments
Previously if a payment was sent with custom records attached, path
finding wouldn't perform a check whether the final node was capable of
receiving custom records in a tlv payload.
2019-12-12 00:15:02 +01:00
Joost Jager
d02de70d20
multi: do not use tlv.Record outside wire format handling
This commit prepares for more manipulation of custom records. A list of
tlv.Record types is more difficult to use than the more basic
map[uint64][]byte.

Furthermore fields and variables are renamed to make them more
consistent.
2019-12-12 00:14:58 +01:00
Joost Jager
b5f1bde604
routing: add error var for pre-built route tried 2019-11-27 15:21:10 +01:00
Joost Jager
f28941c7e4
routing+routerrpc+lncli: enable last hop restriction for payments 2019-11-18 21:03:03 +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
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
e7a457f1ce
routing: query bandwidth hints before each payment attempt
Previously the bandwidth hints were only queried once per payment. This
did not allow for concurrent payments changing channel balances.
2019-08-17 10:24:07 +02: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
nsa
3dde7bc4e2 routing: adding the BlockPadding value to sendpayment
This commit adds the BlockPadding value (currently 3) to sendpayment
calls so that if some blocks are mined while the htlc is in-flight, the
exit hop won't reject it.
2019-07-23 21:03:11 -04:00
Joost Jager
34b264a3d8
routing: create PathFindingConfig for global parameters 2019-07-18 15:49:25 +02:00
Joost Jager
8055bcf2e0
routing: report failures to mission control directly
As there is no more state kept in the payment session, failure reporting
can go straight to mission control.
2019-07-13 22:38:25 +02:00
Joost Jager
dc13da5abb
routing: move second chance logic into mission control
If nodes return a channel policy related failure, they may get a second
chance. Our graph may not be up to date. Previously this logic was
contained in the payment session.

This commit moves that into global mission control and thereby removes
the last mission control state that was kept on the payment level.

Because mission control is not aware of the relation between payment
attempts and payments, the second chance logic is no longer based
tracking second chances given per payment.

Instead a time based approach is used. If a node reports a policy
failure that prevents forwarding to its peer, it will get a second
chance. But it will get it only if the previous second chance was
long enough ago.

Also those second chances are no longer dependent on whether an
associated channel update is valid. It will get the second chance
regardless, to prevent creating a dependency between mission control and
the graph. This would interfer with (future) replay of history, because
the graph may not be the same anymore at that point.
2019-07-13 22:38:23 +02:00
Joost Jager
37e2751695
routing+routerrpc: isolate payment session source from mission control 2019-07-13 22:38:19 +02:00
Joost Jager
054e42f680
routing+routerrpc: expose mission control parameters in lnd config
This commit exposes the three main parameters that influence mission
control and path finding to the user as command line or config file
flags. It allows for fine-tuning for optimal results.
2019-06-04 13:22:50 +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
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
Johan T. Halseth
f4306b1178
routing/payment_session+router: make PaymentSession interface 2019-05-27 20:18:58 +02:00
Johan T. Halseth
adc4640f4f
routing: export MissionControl 2019-05-27 20:18:58 +02:00
Joost Jager
ba3fa94268
lnrpc+routing: Only accept a single route for SendToRoute 2019-05-15 11:54:46 +02:00
Conner Fromknecht
17b2140cb5
multi: fix spelling mistakes 2019-05-04 15:35:37 -07:00
Johan T. Halseth
ee257fd0eb
multi: move Route to sub-pkg routing/route 2019-04-29 14:52:33 +02:00
Joost Jager
06cd64cbbc
routing: add cltv limit to payment session 2019-03-19 10:36:51 +01:00
Joost Jager
e3bb3d46a2
routing: abstract path finding interface 2019-03-19 10:36:48 +01:00
Joost Jager
7719bc432f
routing: take Vertex types as path finding source and target nodes
Currently public keys are represented either as a 33-byte array (Vertex) or as a
btcec.PublicKey struct. The latter isn't useable as index into maps and
cannot be used easily in compares. Therefore the 33-byte array
representation is used predominantly throughout the code base.

This commit converts the argument types of source and target nodes for
path finding to Vertex. Path finding executes no crypto operations and
using Vertex simplifies the code.

Additionally, it prepares for the path finding source parameter to be
exposed over rpc in a follow up commit without requiring conversion back
and forth between Vertex and btcec.PublicKey.
2019-03-06 15:31:00 +01:00