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
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. |
| @@ -1596,6 +1596,10 @@ type LightningPayment struct { | |||
| // hop. If nil, any channel may be used. | |||
| OutgoingChannelID *uint64 | |||
|
|
|||
| // LastHop is the pubkey of the last node before the final destination | |||
| // is reached. If nil, any node may be used. | |||
| LastHop *route.Vertex | |||
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
This PR adds an optional last hop restriction to payments.