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.

[WaspLN]

Great feature. But when I tried to test it, I get the Error "[lncli] invalid vertex string length of 18, want 66"

./lncli payinvoice --allow_self_payment --outgoing_chan_id=627075670727393280 --last_hop=629203225665667072 --pay_req=lnbc200n1p0yvcaspp5np5m8g5jc6tzjj9n2fuw7we8d6hatcckewlhtljnnx5a5d2n7xnsdqqcqzpgsp5c3t24zcxua7424x0gtudkfqjdym0tcxf65rgh2pdu78mxw8hccys9qy9qsqgvnavsn5wz7a9xt3nese3rfgz488c3qc64tcav6zj5wcupmdsfc5muku93qmuelg3a0x0g8auj0xdm9tx4d44ppwxad8ffjrqq29ljsqq7lzua
[lncli] invalid vertex string length of 18, want 66

The channel_point is 66 chars long, but chan_id is 18 characters long. If I use channel_point in the place of chan_id I get a parse error

./lncli payinvoice --allow_self_payment --outgoing_chan_id=a7344c7a373612d3dfb56781a4122c015b6d8a2e6ea192974cc05637ce591666:0 --last_hop=12111e9c2f604734ddf907ea2fc3833aab53fb0f7fd5cb109f06effe8070cd28 --pay_req=lnbc200n1p0yvcaspp5np5m8g5jc6tzjj9n2fuw7we8d6hatcckewlhtljnnx5a5d2n7xnsdqqcqzpgsp5c3t24zcxua7424x0gtudkfqjdym0tcxf65rgh2pdu78mxw8hccys9qy9qsqgvnavsn5wz7a9xt3nese3rfgz488c3qc64tcav6zj5wcupmdsfc5muku93qmuelg3a0x0g8auj0xdm9tx4d44ppwxad8ffjrqq29ljsqq7lzua
Incorrect Usage.
[lncli] invalid value "a7344c7a373612d3dfb56781a4122c015b6d8a2e6ea192974cc05637ce591666:0" for flag -outgoing_chan_id: parse error

It seems LND is not happy with my chan_id and I don't know why ?

[joostjager]

Last hop needs to be a node public key (33 bytes)

[WaspLN]

Yes, that worked! I missed that little detail. Thank you!