Commit Graph

333 Commits

Author SHA1 Message Date
Johan T. Halseth
c4fc72d573
routerrpc+routing: set AMP options for payments specified as AMP in SendPayment 2021-04-27 09:47:23 +02:00
Johan T. Halseth
56a2c65477
router: use SetID as identifier for SendToRoute AMP-payments 2021-04-27 09:47:23 +02: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
Johan T. Halseth
5531b812e3
routing: use AMP shard tracker
We'll use the AMP-specific ShardTracker for payments having non-nil
AMPOptions.
2021-04-27 09:47:23 +02:00
Johan T. Halseth
e1399fb1ec
routing/router: use attempt's unique hash if set on restart 2021-04-27 09:45:13 +02:00
Johan T. Halseth
41ae3530a3
routing/payment_lifecycle: use ShardTracker to track shards
We'll let the payment's lifecycle register each shard it's sending with
the ShardTracker, canceling failed shards. This will be the foundation
for correct AMP derivation for each shard we'll send.
2021-04-27 09:43:40 +02:00
Johan T. Halseth
a9f19b100b
router+switch: rename paymentID->attemptID
To distinguish the attempt's unique ID from the overall payment
identifier, we name it attemptID everywhere, and note that the
paymentHash argument won't be the actual payment hash for AMP payments.
2021-04-27 08:27:33 +02:00
Johan T. Halseth
7795353e9f
channeldb: return full payment for inflight payments
We might as well return all info, and we'll need the individual HTLCs
in later commits.
2021-04-27 08:27:32 +02:00
Olaoluwa Osuntokun
7b589e5811
routing: add strict zombie pruning as a config level param
In this commit, we add strict zombie pruning as a config level param.
This allow us to add the option for those that want a tighter graph, and
not change the default composition of the channel graph for most users
over night.

In addition, we expand the test case slightly by testing that the self
node won't be pruned, but also that if there's a node with only a single
known stale edge, then both variants will prune that edge.
2021-04-21 13:56:27 -05:00
Conner Fromknecht
e3a8b3b0c4
routing/router: prune zombies when either end is stale 2021-04-21 13:56:21 -05:00
Olaoluwa Osuntokun
a329c80612
Merge pull request #5133 from wpaulino/routing-validation-cancel-deps
discovery+routing: cancel dependent jobs if parent validation fails
2021-04-01 18:32:58 -07:00
Johan T. Halseth
1231c90a19
routing: avoid open DB transaction if no zombies to prune
We add a simple length check to the channels to be pruned to avoid
opening the DB if there is nothing to be done.
2021-03-30 11:04:13 +02:00
Johan T. Halseth
a0f3624303
routing: delay initial zombie prune by 30 sec
Since zombie pruning can be very slow on some devices (e.g. mobile) it
would stall lnd startup. Since it is not essential for pruning to be
finished for lnd to be functional, we instead delay the initial prune by
30 seconds.

Note that we could also wait for the graphPruneInterval to tick, but
since this is by default 2 hours, it is unlikely that a mobile app will
ever be open that long.
2021-03-30 11:04:13 +02:00
Wilmer Paulino
393111cea9
discovery+routing: cancel dependent jobs if parent validation fails
Previously, we would always allow dependent jobs to be processed,
regardless of the result of its parent job's validation. This isn't
correct, as a parent job contains actions necessary to successfully
process a dependent job. A prime example of this can be found within the
AuthenticatedGossiper, where an incoming channel announcement and update
are both processed, but if the channel announcement job fails to
complete, then the gossiper is unable to properly validate the update.
This commit aims to address this by preventing the dependent jobs to
run.
2021-03-23 11:56:51 -07:00
Conner Fromknecht
f7c5236bf6
routing: dial back max concurrent block fetches
This commit reduces the number of concurrent validation operations the
router will perform when fully validating the channel graph. Reports
from several users indicate that GetInfo would hang for several minutes,
which is believed to be caused by attempting to validate massive amounts
of channels in parallel. This commit returns the limit back to its
original state before adding the batched gossip improvements.

We keep the 1000 concurrent validation request limit for
AssumeChannelValid, since we don't fetch blocks in that case. This
allows us to still keep the performance benefits on mobile/low-resource
devices.
2021-02-17 18:17:09 -08:00
Olaoluwa Osuntokun
7398e59927
lnrpc/routerrpc+routing: add new MaxShardAmt field to LightningPayment 2021-02-15 19:31:49 -08:00
Johan T. Halseth
7e34132c53
routing: let graph methods take scheduler option 2021-02-10 23:54:03 +01:00
Olaoluwa Osuntokun
7e298f1434
Merge pull request #3367 from cfromknecht/batched-graph-updates
Batched graph updates
2020-11-25 18:40:40 -08:00
Olaoluwa Osuntokun
d996607470
routing+lnrpc: extend BuildRoute to accept raw payAddr
In this commit, we extend the `BuildRoute` method and RPC on the router
sub-server to accept a raw payment address which will be included as
part of an MPP payload for the finla hop. This change actually also
allows users to craft their own MPP paths using BuildRoute+SendToRoute.
Our primary goal however, was to fix some broken itests since we now
require the payAddr to be present for ALL payments other than key send
payments.
2020-11-25 16:32:02 -08:00
Conner Fromknecht
e8c545e909
routing/router: increase validation barrier size to 1000
This allows for a 1000 different persistent operations to proceed
concurrently. Now that we are batching operations at the db level, the
average number of outstanding requests will be higher since the commit
latency has increased. To compensate, we allow for more outstanding
requests to keep the router busy while batches are constructed.
2020-11-24 16:40:10 -08:00
Johan T. Halseth
df049ad755
routing: promote shard logs on resume and terminal failure to Info 2020-11-24 14:59:39 +01:00
Johan T. Halseth
90a59fe70f
router: call CleanStore on startup 2020-10-06 10:46:04 +02:00
Conner Fromknecht
6622c4814e
multi: enforce routing.MinCLTVDelta=18 for invoices + chanupd
This commit clamps all user-chosen CLTVs in LND to be at least 18, which
is the new conservative value used in the sepc. This minimum is applied
uniformly to forwarding CLTV deltas (via channel updates) as well as
final CLTV deltas for new invoices.
2020-07-24 13:13:56 -07:00
Conner Fromknecht
d0d2ca403d
multi: rename ReadTx to RTx 2020-05-26 18:20:37 -07:00
Conner Fromknecht
2f84d1a819
Merge pull request #4280 from cfromknecht/read-for-each-node
channeldb: remove Tx arg from ForEachNode
2020-05-13 16:37:10 -07:00
Conner Fromknecht
90d3bf532d
channeldb+routing: remove tx arg for ForEachNode 2020-05-12 17:53:20 -07:00
Joost Jager
674c199047
routing: return full htlc attempt from router 2020-05-12 19:56:52 +02:00
Joost Jager
cc37485432
routing: return full htlc attempt from shard handler 2020-05-12 19:56:50 +02:00
Joost Jager
c33d94ff27
routing+routerrpc: add multiple outgoing channel restriction 2020-05-12 07:17:24 +02:00
Andras Banki-Horvath
556e3525ea misc: fix error formatting in multiple files 2020-04-24 19:15:08 +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
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
Johan T. Halseth
36a80b4d51
routing/router: enable MPP sends for SendToRoute
This commit enables MPP sends for SendToRoute, by allowing launching
another payment attempt if the hash is already registered with the
ControlTower.

We also set the total payment amount of of the payment from mpp record,
to indicate that the shard value might be different from the total
payment value.

We only mark non-MPP payments as failed in the database after
encountering a failure, since we might want to try more shards for MPP.
For now this means that MPP sendToRoute payments will be failed
only after a restart has happened.
2020-04-02 19:29:15 +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
4509c4f3a9
routing: move ErrMaxRouteHopsExceeded check
Now that SendToRoute is no longer using the payment lifecycle, we move
the max hop check out of the payment shard's launch() method, and return
the error directly, such that it can be handled in SendToRoute.
2020-04-02 10:24:35 +02:00
Johan T. Halseth
6cc162e0b0
router: make sendToRoute omit payment lifecycle
Instead of having SendToRoute pull routes from the payment session in
the payment lifecycle, we utilize the new methods on the paymentShard to
launch and collect the result for this single route.

This also let us remove the check for noRouteError, as we will always
have the result from the tried attempt returned. A result of this is
that we can finally remove lastError from the payment lifecycle (see
next commits).
2020-04-02 10:24:35 +02:00
Johan T. Halseth
9712dd1a7f
routing/payment_lifecycle: extract attempt sending logic
Define shardHandler which is a struct holding what is needed to send
attempts along given routes. The reason we define the logic on this
struct instead of the paymentLifecycle is that we later will make
SendToRoute calls not go through the payment lifecycle, but only using
this struct.

The launch shard is responsible for registering the attempt with the
control tower, failing it if the launch fails. Note that it is NOT
responsible for marking the _payment_ failed in case a terminal error is
encountered. This is important since we will later reuse this method for
SendToRoute, where whether to fail the payment cannot be decided on the
shard level.
2020-04-02 10:24:34 +02:00
Johan T. Halseth
bcca1ab821
routing/payment_lifeycle: remove payment level attempt and circuit
We replace the cached attempt, and instead use the control tower
(database) to fetch any in-flight attempt. This is done as a
preparation for having multiple attempts in flight.

In addition we remove the cached circuit, as it won't be applicable when
multiple shards are in flight.

Instead of tracking the attemp we consult the database on every
iteration, and pick up any existing attempt. This also let us avoid
having to pass in the existing attempts from the payment loop, as we
just fetch them direclty.
2020-04-02 10:24:34 +02:00
Johan T. Halseth
79227bab3a
routing/route: define route.ReceiverAmt() method 2020-04-02 10:24:34 +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
f9eeb6b41f
routing/router+lifecycle: remove LightningPayment from payment lifecycle
Now that the information needed is stored by the paymentSession, we no
longer need to pass the LightningPayment into the payment lifecycle.
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
Olaoluwa Osuntokun
28bbaa2a94
routing: convert to use new kvdb abstraction 2020-03-18 19:34:58 -07:00
Joost Jager
48c0e42c26
channeldb+routing: store all payment htlcs
This commit converts the database structure of a payment so that it can
not just store the last htlc attempt, but all attempts that have been
made. This is a preparation for mpp sending.

In addition to that, we now also persist the fail time of an htlc. In a
later commit, the full failure reason will be added as well.

A key change is made to the control tower interface. Previously the
control tower wasn't aware of individual htlc outcomes. The payment
remained in-flight with the latest attempt recorded, but an outcome was
only set when the payment finished. With this commit, the outcome of
every htlc is expected by the control tower and recorded in the
database.

Co-authored-by: Johan T. Halseth <johanth@gmail.com>
2020-03-09 18:31:33 +01:00
Joost Jager
8558534417
routing: add clock to router config 2020-03-09 11:43:44 +01:00
Johan T. Halseth
bee2380441
channeldb: rename PaymentAttemptInfo to HTLCAttemptInfo
To better distinguish payments from HTLCs, we rename the attempt info
struct to HTLCAttemptInfo. We also embed it into the HTLCAttempt struct,
to avoid having to duplicate this information.

The paymentID term is renamed to attemptID.
2020-03-09 11:43:26 +01:00
Joost Jager
967b4b2dc3
channeldb: remove redundant MPPaymentCreationInfo struct
MPPaymentCreationInfo and PaymentCreationInfo are identical except for
the naming of CreationTime/CreationDate.
2020-03-09 11:43:24 +01:00