routing: non-strict path finding#3558
Conversation
joostjager
added
incomplete
joostjager
force-pushed
the
non-strict-pathfinding
branch
5 times, most recently
from
6dd4409 to
1bcafde
Compare
There was a problem hiding this comment.
should we cap this at 21M * 100M * 1000 msat instead? introduce in same commit as usage?
There was a problem hiding this comment.
It's the maximum amount of millisatoshis that could ever exist on the chain. Litecoin would have a different amount though.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I took a different approach where I don't squash all policies together. Instead, the optimal policy is returned based on the actual amount.
joostjager
force-pushed
the
non-strict-pathfinding
branch
from
1bcafde to
3a6660a
Compare
|
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.
|
|
Results when filtered for channels between bos list nodes is 20%.
|
joostjager
force-pushed
the
non-strict-pathfinding
branch
from
3a6660a to
1a473cc
Compare
joostjager
force-pushed
the
non-strict-pathfinding
branch
from
1a473cc to
bcbfcc1
Compare
joostjager
added
v0.9.0
and removed
incomplete
wpaulino
left a comment
wpaulino
left a comment
There was a problem hiding this comment.
Nice refactor on BuildRoute!
There was a problem hiding this comment.
It's the maximum amount of millisatoshis that could ever exist on the chain. Litecoin would have a different amount though.
joostjager
force-pushed
the
non-strict-pathfinding
branch
from
bcbfcc1 to
9fe7b33
Compare
|
Travis failed with: Looks unrelated, but is it known? |
Looks unrelated indeed. Maybe caused by the log commit ticker... Could be fixed by #2927 |
joostjager
force-pushed
the
non-strict-pathfinding
branch
from
9fe7b33 to
fb486c4
Compare
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
force-pushed
the
non-strict-pathfinding
branch
from
fb486c4 to
a497a59
Compare
cfromknecht
left a comment
cfromknecht
left a comment
There was a problem hiding this comment.
Very clean and well tested!! LGTM ✅
joostjager
force-pushed
the
non-strict-pathfinding
branch
from
a497a59 to
729c3a6
Compare
3 participants
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.