routing: last hop restriction#3739
Conversation
Previously both paths were equal cost, so it could also be a coincedence that the path with the outgoing restriction would be chosen.
joostjager
force-pushed
the
incoming-restriction
branch
2 times, most recently
from
9f28670 to
59ec4fe
Compare
joostjager
force-pushed
the
incoming-restriction
branch
from
59ec4fe to
cc60ee8
Compare
guggero
left a comment
guggero
left a comment
There was a problem hiding this comment.
Very nice and clean PR! This will allow us to craft rebalance payments without external tools, right?
LGTM, there's only a small comment that is non-blocking.
joostjager
force-pushed
the
incoming-restriction
branch
2 times, most recently
from
190416d to
a21c7d7
Compare
In combination with #3736 it does. Also we can use this to loop into a specific channel. |
routing/router.go
Outdated
There was a problem hiding this comment.
Do we care about validating whether this is an existing node in the graph? Path finding would result in unable to find a path to destination, which can be ambiguous.
There was a problem hiding this comment.
We also don't do this for the outgoing channel restriction. As this is advanced functionality, I am ok with leaving it up to the caller to make sure this doesn't happen. What do you think?
Maybe if we start fixing #1680, we can add two new payment failures:
no_outgoing_channel (with enough balance and not filtered out) and no_last_hop (with enough capacity and not filtered out).
There was a problem hiding this comment.
We can defer it until then.
joostjager
force-pushed
the
incoming-restriction
branch
from
a21c7d7 to
f28941c
Compare
3 participants
This PR adds an optional last hop restriction to payments.