Commit Graph

12 Commits

Author SHA1 Message Date
Joost Jager
e3b9ed5cd8
Merge pull request #3863 from joostjager/fix-result-interpretation
routing: fix gap in result interpretation
2019-12-20 14:42:19 +01:00
carla
25a8773736
routing: interpret mpp timeout failues
This commit adds success mission control
results for all hops along the route in
a mpp timeout and takes no action for
the final hop along the route. This is a
temporary measure to prevent the default
logic from penalizing the final node while
we decide how to penalize mpp timeouts.
2019-12-20 13:02:30 +02:00
Joost Jager
a3a1b488a6
routing: fix gap in result interpretation
Fixes an off by one error that skipped assigning a success pair. Added a
test that previously failed because of this bug.
2019-12-20 09:14:15 +01:00
Joost Jager
62f8cca75b
routing+routerrpc: also expose amt for success results in mc 2019-11-22 11:17:26 +01:00
Conner Fromknecht
d08e8ddd61
routing/result_interpretation: process InvalidOnionPayload
An InvalidOnionPayload implies that the onion was successfully received
by the reporting node, but that they were unable to extract the
contents. Since we assume our own behavior is correct, this mostly
likely poins to an error in the reporter's implementation or that we
sent an unknown required type. Therefore we only penalize that single
hop, and consider the failure terminal if the receiver reported it.
2019-10-30 21:20:08 -07:00
Conner Fromknecht
2f8021d8db
routing/result_interpretation: fix off-by-one for incoming failure
Previously we would not mark a success for the first hop if the fail
source index was 2. We also add a test to assert this behavior.
2019-10-30 21:18:52 -07:00
Joost Jager
559d3c0910
routing: also fail pairs for node-level failures
This commit modifies the interpretation of node-level failures.
Previously only the failing node was marked. With this commit, also the
incoming and outgoing connections involved in the route are marked as
failed.

The change prepares for the removal of node-level failures in mission
control probability estimation.
2019-10-22 15:52:34 +02:00
Joost Jager
aefbee78d6
routing: use pairResult constructors
To make it explicit whether a failure or a success result is
instantiated.
2019-10-22 15:52:28 +02:00
Joost Jager
f60e4b1e14
lnwire+htlcswitch: report height for invalid payment details failure
Extends the invalid payment details failure with the new accept height
field. This allows sender to distinguish between a genuine invalid
details situation and a delay caused by intermediate nodes.
2019-09-16 10:10:20 +02:00
Joost Jager
ff0c5a0d5e
routing: process successes in mission control
This commit modifies paymentLifecycle so that it not only feeds
failures into mission control, but successes as well.
This allows for more accurate probability estimates. Previously,
the success probability for a successful pair and a pair with
no history was equal. There was no force that pushed towards
previously successful routes.
2019-08-23 09:15:41 +02:00
Joost Jager
d9ec158412
routing: stricter payment result interpretation
This commit overhauls the interpretation of failed payments. It changes
the interpretation rules so that we always apply the strongest possible
set of penalties, without making assumptions that would hurt good nodes.

Main changes are:

- Apply different rule sets for intermediate and final nodes. Both types
of nodes have different sets of failures that we expect. Penalize nodes
that send unexpected failure messages.

- Distinguish between direct payments and multi-hop payments. For direct
payments, we can infer more about the performance of our peer because we
trust ourselves.

- In many cases it is impossible for the sender to determine which of
the two nodes in a pair is responsible for the failure. In this
situation, we now penalize bidirectionally. This does not hurt the good
node of the pair, because only its connection to a bad node is
penalized.

- Previously we always penalized the outgoing connection of the
reporting node. This is incorrect for policy related failures. For
policy related failures, it could also be that the reporting node
received a wrongly crafted htlc from its predecessor. By penalizing the
incoming channel, we surely hit the responsible node.

- FailExpiryTooSoon is a failure that could have been caused by any node
up to the reporting node by delaying forwarding of the htlc. We don't
know which node is responsible, therefore we now penalize all node pairs
in the route.
2019-08-17 10:24:09 +02:00
Joost Jager
45dacd0df1
routing: isolate failure interpretation from mission control
This commit moves the payment outcome interpretation logic into a
separate file. Also, mission control isn't updated directly anymore, but
results are stored in an interpretedResult struct. This allows the
mission control state to be locked for a minimum amount of time and
makes it easier to unit test the result interpretation.
2019-08-17 10:23:59 +02:00