search

lightningdevkit / rust-lightning

A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!
Other
1.14k stars 357 forks source link

Rebalance route finder #959

Open TheBlueMatt opened 3 years ago

TheBlueMatt commented 3 years ago

We should build a second get_route-like method that, instead of seeking to send funds from one node to another, seeks to balance the funds in a set of ChannelDetails objects by routing through a NetworkGraph back to the same node.

abhik-99 commented 3 years ago

Hey, if no one is working on this, may I take a shot at it?

TheBlueMatt commented 3 years ago

Go for it! I imagine it will be simplest to refactor the existing get_route into a thin wrapper and a helper which does the work and supports both rebalance and regular route finding (or at least is used to calculate a path from our peer back to us without the to-be-balanced channel being used).

On Sep 9, 2021, at 08:34, Abhik Banerjee @.***> wrote:

 Hey, if no one is working on this, may I take a shot at it?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

abhik-99 commented 3 years ago

I was actually thinking about implementing a method for this paper by Rene Pickhardt. But I take it at this time a Just in Time Routing scheme would be favourable? I can follow c-lightning implementation by cdecker.

The thought of giving the user a choice to select the rebalancing option or finding an alternative route sounds good.

TheBlueMatt commented 3 years ago

If we want a parallel route finder (which we could totally do) we should support both routefinders for rebalance-route-finding. For rebalancing we probably don’t want something like the Pickhardt route-finding since we don’t really care about reliability, we just care about minimizing fees.

Pickhardt route-finding we may not want to do anytime soon anyway - it is likely too restrictive in terms of requiring base fees and may overpay in fees, we should first experiment with fee-based scoring of the form “I’m willing to pay X extra in fees to have an N% more reliable payment” which is rather simple to implement. That is something Jeff is currently working on.

On Sep 12, 2021, at 10:46, Abhik Banerjee @.***> wrote:

 I was actually thinking about implementing a method for this paper by Rene Pickhardt. But I take it at this time a Just in Time Routing scheme would be favourable? I can follow c-lightning implementation by cdecker.

The thought of giving the user a choice to select the rebalancing option or finding an alternative route sounds good.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

abhik-99 commented 3 years ago

Got it!

abhik-99 commented 2 years ago

Hey, sorry but I cannot work on this issue at this time. So if anyone is interested, please feel free to take it up.

dunxen commented 2 years ago

I can take a look at this if it is still relevant?

TheBlueMatt commented 2 years ago

Yep, go for it! I think there's somewhat less interest in lightning in rebalancing in general but its definitely still something we should support, for users who want it.

dunxen commented 2 years ago

Got tied up in Qala.dev stuff, but planning to continue with this in a few days. No ETA though :)

dunxen commented 2 years ago

Almost have a PR up for this for early review