Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

routing: non-strict path finding #3558

Merged
merged 3 commits into from Oct 30, 2019

Conversation

@joostjager
Copy link
Collaborator

joostjager commented Sep 30, 2019

This pr makes path finding (and build route) aware of non-strict forwarding. Before deciding on a path edge, it calculates a single unified policy for the complete set of channels between two nodes.

@joostjager joostjager requested review from halseth and Roasbeef as code owners Sep 30, 2019
@joostjager joostjager removed request for Roasbeef and halseth Sep 30, 2019
@joostjager joostjager force-pushed the joostjager:non-strict-pathfinding branch 5 times, most recently from 6dd4409 to 1bcafde Sep 30, 2019
@joostjager joostjager requested a review from halseth Sep 30, 2019

// MaxMilliSatoshi is the maximum number of msats that can be expressed
// in this data type.
MaxMilliSatoshi = ^MilliSatoshi(0)

This comment has been minimized.

Copy link
@cfromknecht

cfromknecht Oct 1, 2019

Collaborator

should we cap this at 21M * 100M * 1000 msat instead? introduce in same commit as usage?

This comment has been minimized.

Copy link
@joostjager

joostjager Oct 1, 2019

Author Collaborator

ltc...?

This comment has been minimized.

Copy link
@wpaulino

wpaulino Oct 23, 2019

Collaborator

It's the maximum amount of millisatoshis that could ever exist on the chain. Litecoin would have a different amount though.

routing/unified_policy.go Outdated Show resolved Hide resolved
routing/unified_policy.go Outdated Show resolved Hide resolved
u.feeProportionalMillionths = policy.FeeProportionalMillionths
}

// For htlc amount constraints, take the widest range.

This comment has been minimized.

Copy link
@cfromknecht

cfromknecht Oct 1, 2019

Collaborator

are we not trying to take the narrowest range, as to be able to satisfy any of the links? maybe we are thinking about the widths differently

This comment has been minimized.

Copy link
@joostjager

joostjager Oct 3, 2019

Author Collaborator

I took a different approach where I don't squash all policies together. Instead, the optimal policy is returned based on the actual amount.

routing/unified_policy.go Outdated Show resolved Hide resolved
routing/unified_policy.go Outdated Show resolved Hide resolved
@joostjager joostjager force-pushed the joostjager:non-strict-pathfinding branch from 1bcafde to 3a6660a Oct 1, 2019
@joostjager joostjager removed the request for review from halseth Oct 1, 2019
@joostjager

This comment has been minimized.

Copy link
Collaborator Author

joostjager commented Oct 2, 2019

Did a quick check how prevalent multiple (advertized) channels between a pair of nodes at the moment. About 7.5% of the node pairs have multiple channels. This doesn't say much though about how often multi-channel node connections are traversed during payments.

lncli describegraph | jq '.edges[] | .node1_pub + " " + .node2_pub' -r | sort | uniq -c | awk '{print $1}' | sort | uniq -c

nof channels node pair count
1 29093
2 1834
3 367
4 102
5 23
6 10
7 3
8 2
9 5
10 1
12 1
15 1
17 1
18 1
29 1
35 1
105 1
150 1
@joostjager

This comment has been minimized.

Copy link
Collaborator Author

joostjager commented Oct 2, 2019

Results when filtered for channels between bos list nodes is 20%.

nof channels node pair count
1 3015
2 427
3 252
4 73
5 15
6 2
7 1
15 1
17 1
@joostjager joostjager force-pushed the joostjager:non-strict-pathfinding branch from 3a6660a to 1a473cc Oct 3, 2019
@joostjager joostjager requested a review from cfromknecht Oct 3, 2019
@joostjager joostjager force-pushed the joostjager:non-strict-pathfinding branch from 1a473cc to bcbfcc1 Oct 3, 2019
@joostjager joostjager added v0.9.0 and removed incomplete labels Oct 6, 2019
@joostjager joostjager added this to the 0.9 milestone Oct 8, 2019
@joostjager joostjager requested a review from wpaulino Oct 21, 2019
@joostjager joostjager added this to WIP in v0.9.0-beta via automation Oct 23, 2019
@joostjager joostjager moved this from WIP to Needs Review in v0.9.0-beta Oct 23, 2019
@joostjager joostjager self-assigned this Oct 23, 2019
Copy link
Collaborator

wpaulino left a comment

Nice refactor on BuildRoute!


// MaxMilliSatoshi is the maximum number of msats that can be expressed
// in this data type.
MaxMilliSatoshi = ^MilliSatoshi(0)

This comment has been minimized.

Copy link
@wpaulino

wpaulino Oct 23, 2019

Collaborator

It's the maximum amount of millisatoshis that could ever exist on the chain. Litecoin would have a different amount though.

routing/unified_policies.go Show resolved Hide resolved
routing/unified_policies.go Show resolved Hide resolved
@joostjager joostjager force-pushed the joostjager:non-strict-pathfinding branch from bcbfcc1 to 9fe7b33 Oct 24, 2019
@joostjager joostjager requested a review from wpaulino Oct 24, 2019
@wpaulino

This comment has been minimized.

Copy link
Collaborator

wpaulino commented Oct 24, 2019

Travis failed with:

--- FAIL: TestChannelLinkWaitForRevocation (10.99s)
    link_test.go:4615: expected RevokeAndAck, got *lnwire.CommitSig

Looks unrelated, but is it known?

@wpaulino wpaulino removed their request for review Oct 24, 2019
@joostjager

This comment has been minimized.

Copy link
Collaborator Author

joostjager commented Oct 24, 2019

Travis failed with:

--- FAIL: TestChannelLinkWaitForRevocation (10.99s)
    link_test.go:4615: expected RevokeAndAck, got *lnwire.CommitSig

Looks unrelated, but is it known?

Looks unrelated indeed. Maybe caused by the log commit ticker... Could be fixed by #2927

@joostjager joostjager force-pushed the joostjager:non-strict-pathfinding branch from 9fe7b33 to fb486c4 Oct 24, 2019
@joostjager joostjager requested a review from wpaulino Oct 24, 2019
joostjager added 2 commits Oct 3, 2019
In this commit we change path finding to no longer consider all channels
between a pair of nodes individually. We assume that nodes forward
non-strict and when we attempt a connection between two nodes, we don't
want to try multiple channels because their policies may not be identical.
Having distinct policies for channel to the same peer is against the
recommendation in the spec, but it happens in the wild. Especially since
we recently changed the default cltv delta value.

What this commit introduces is a unified policy. This can be looked upon
as the greatest common denominator of all policies and should maximize
the probability of getting the payment forwarded.
@joostjager joostjager force-pushed the joostjager:non-strict-pathfinding branch from fb486c4 to a497a59 Oct 25, 2019
Copy link
Collaborator

cfromknecht left a comment

Very clean and well tested!! LGTM

routing/unified_policies.go Outdated Show resolved Hide resolved
v0.9.0-beta automation moved this from Needs Review to Approved Oct 29, 2019
@joostjager joostjager force-pushed the joostjager:non-strict-pathfinding branch from a497a59 to 729c3a6 Oct 29, 2019
@joostjager joostjager merged commit a8f077a into lightningnetwork:master Oct 30, 2019
1 of 2 checks passed
1 of 2 checks passed
coverage/coveralls Coverage decreased (-0.04%) to 62.967%
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
v0.9.0-beta automation moved this from Approved to Done Oct 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
v0.9.0-beta
  
Done
3 participants
You can’t perform that action at this time.