Ability to Route given a sending amount, not receive amount

[TheBlueMatt]

This will probably require some multi-pass magic, but users today are used to being able to send their full balance, minus fees. In lightning wallets today that's not really possible, because you calculate a route given an amount for the recipient, not an amount for the sender (ie fees-added, not fees-deducted). Its not really directly possible to do this with Dijkstras, but we can emulate it with a few passes, and we probably should, eventually.

[jurvis]

hi @TheBlueMatt i'm interested to pick up this issue. just to clarify that I am understanding this correctly:

since pathfinding in lightning goes from recipient to sender, for each candidate path, we only know about its total sending amount (receive amount + accumulated fees) once the algorithm gets back to the sender. therefore, the challenge with sending full balances is that it is difficult to anticipate what this sum will be ahead of the pathfinding process?

also can you say more about what you mean by emulating a few passes? thank you!

[TheBlueMatt]

Yea, so my thinking here is basically we just wrap a "normal" pathfinding attempt with (sending_amount - delta) as the receive amount, or maybe even sending-amount, and then we recalculate the fees at the end to make it send the correct amount afterwards. By "multi-pass" I meant we may have to retry pathfinding a few times with different target amounts depending on some edge cases, picking the best path we find across a few tries.

[jkczyz]

Trying to understand what the use use case and what can be sent in practice. Is the sending amount ChannelDetails::outbound_capacity_msat over all channels or just one? The docs on that say the amount might not be exact and presumably does not include the channel reserve.

[TheBlueMatt]

Yes, the goal would be to send as much as you're allowed to, which would be balance - channel reserve, presumably across all channels. Indeed, may need to fix #1126 first.