routing: allow route to self

[joostjager]

This PR makes it possible to find routes to yourself. It is useful for rebalancing purposes if combined with #3739 and an outgoing channel restriction.

Usage from the command line:

1. lncli addinvoice <amt>
2. lncli payinvoice --allow_self_payment --outgoing_chan_id <outgoing_chan> --last_hop <last_hop> <payreq_from_1>

This will push out amt through outgoing_chan back to yourself via one of your channels with your peer last_hop. The exact incoming channel cannot be specified because routing nodes forward non-strict.

Note that if you pay to yourself without any of these restrictions, it may happen that the payment comes back in through the same channel that was used to send it out. In that case balances don't change. They may only go down because of the routing fees paid.

Fixes #1645

[guggero]

Clean and well crafted PR!
It's very nice to see that we can now rebalance easily, even through the command line.

Only found a few nits, nothing critical.

[wpaulino]

Note that if you pay to yourself without any of these restrictions, it may happen that the payment comes back in through the same channel that was used to send it out. In that case balances don't change. They may only go down because of the routing fees paid.

Given that this doesn't really have a use case, perhaps we could detect this and return an error?

[joostjager]

Given that this doesn't really have a use case, perhaps we could detect this and return an error?

I wouldn't really want to hard block this. I think we can assume that people using send to self know what they are doing. I also think we cannot really rule out that such use case would emerge at some point. There is for example the trick where you drop off more routing fees than required as a way to do spontaneous payment.

[cfromknecht]

The exact incoming channel cannot be specified because routing nodes forward non-strict.

We may not be able to choose which channel the HTLC is forwarded over, but we can reject the payment if it doesn't come over the intended channel and retry. Now that we index the invoice htlcs by circuit key, it should be straight forward (apart from needing to add this restriction on the invoice).

Note that if you pay to yourself without any of these restrictions, it may happen that the payment comes back in through the same channel that was used to send it out. In that case balances don't change. They may only go down because of the routing fees paid.

I don't think this would be the expected behavior for simply calling payinvoice <payreq>, and seems pretty easy to mess up. IMO this should produce a warning when source==destination, especially considering it changes the existing behavior which would normally fail. Perhaps adding an --allow-cycle flag would suffice?

[joostjager]

We may not be able to choose which channel the HTLC is forwarded over, but we can reject the payment if it doesn't come over the intended channel and retry. Now that we index the invoice htlcs by circuit key, it should be straight forward (apart from needing to add this restriction on the invoice).

I consider this out of scope for this PR? It is definitely useful functionality, also to prevent tying up capital on expensive peers.

I don't think this would be the expected behavior for simply calling payinvoice , and seems pretty easy to mess up. IMO this should produce a warning when source==destination, especially considering it changes the existing behavior which would normally fail. Perhaps adding an --allow-cycle flag would suffice?

Flag added

[cfromknecht]

LGTM 🍣

[ZapUser77]

Thanks. Glad to see that merged in.