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
|
|
||
| // MaxMilliSatoshi is the maximum number of msats that can be expressed | ||
| // in this data type. | ||
| MaxMilliSatoshi = ^MilliSatoshi(0) |
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.
routing/unified_policy.go
Outdated
| u.feeProportionalMillionths = policy.FeeProportionalMillionths | ||
| } | ||
|
|
||
| // For htlc amount constraints, take the widest range. |
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
|
|
||
| // MaxMilliSatoshi is the maximum number of msats that can be expressed | ||
| // in this data type. | ||
| MaxMilliSatoshi = ^MilliSatoshi(0) |
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
joostjager
force-pushed
the
non-strict-pathfinding
branch
from
a497a59
to
729c3a6
Compare
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.