Lightning: Send payment through specific channel

[andrewtoth]

I can't seem to find a way to get a route outbound using a specific channel of our node. The best I can see is using getroute and exclude every other one of our channels. Is there a better way to do this? If not, I propose a feature request for getting a route or making a payment using only a specific channel or set of channels.

[billygarrison]

I wrote a Python script that does exactly this. It calls getroute from the node you want to pay through to the payee node specified in the invoice. It then adds a hop to the start of the route from you to the "pay-through node" (the script calculates the fee & delay). It then uses sendpay to send the payment along that route.

I plan on converting this to a plugin and publishing it once I get a bit more testing in. This issue just pushed it to the top of my Bitcoin priority list! Hopefully I can get it done this weekend.

[trueptolemy]

@billygarrison It sounds coooool!

[cdecker]

Depending on how common this use-case is we might add this functionality directly into getroute. Would you mind sharing how you are using it, to get an idea of what this would facilitate?

[billygarrison]

The main use-case I can think of is channel rebalancing. If I have a channel with only outgoing capacity, then I will choose to pay through that channel to rebalance it.

It could also be useful if you are expecting a payment to come in through a certain channel, and want pay through the channel to increase your inbound capacity.

If adding a "pay-through" channel option to getroute, might I recommend adding a "receive-through" option as well?

[andrewtoth]

Rebalancing a channel using a reverse submarine swap, a la https://github.com/lightninglabs/loop. However, as @billygarrison has suggested above, using a submarine swap to rebalance would also require a "receive-through" option to specify a set of channels to receive a payment.

[cdecker]

There is no good way for us to force an incoming payment through a certain channel, since we're not the ones computing the route, the sender is. We'll be able to do that using the rendezvous routing eventually.

Changing getroute is always a bit of a balancing act, since we end up with a kitchensync-style API. For your case, the channel being one of your own channels, I'd suggest using exclude. This works in the following manner: let's assume we have a small network of 4 nodes:

A --- B
|     |
C --- D

and we want to rebalance the channel AB. If we want to traverse AB from A to B we compute a route B -> A (fromid=B) and exclude AB (giving us BC, CD, DA as a result). We then prepend AB to that route and we have a circular route that rebalances AB like we wanted. The same can also be used in reverse, by computing A -> B and then appending BA to the route.

Any more complex routing is likely better suited by exporting the network view and computing the route externally.

[andrewtoth]

That works for a circular rebalancing. However, for a reverse submarine swap, you send a payment out one way and receive the funds on-chain, so no need to have a circular route. For this case, being able to select which channel specifically is a lot easier than having to exclude every other channel.

[billygarrison]

@cdecker my "receive-through" suggestion for getroute was intended for when you are sending a payment, not receiving. It would be used to choose which of id's channels they receive the payment through.

In your rebalancing example above, it would save the last step of prepending/appending a hop.

With that said, I can see how adding these very specific options to getroute could get out of hand, and it may just be better handled with plugins.

[ZmnSCPxj]

exclude already covers all such abilities; a plugin can be built on top of getroute and use exclude and listchannels (and double-check the result from getroute: a new channel might be added to the view in between listchannels and getroute) to provide send-through OR receive-through options.

Propose solving via plugin and closing here.