[c-lightning] Routing: bias against smaller channels

[michael at schmoock.net]

Hi,

I'm currently thinking about the same issue while I'm polishing the 
rebalance plugin.
My current thoughts on that: This should probably not be done by 
changing the getroute
code but by the one that is using getroute in a way like for example:

- Start trying shorter routes first via "maxhops" parameter.
- In the first iteration use a lot higher "msatoshi" value than needed, 
for example by a factor of 4 times bigger.
- When you get "route not found errors" decrease the msatoshi factor and 
retry getroute.
- When you reached a msatoshi factor of 1 (neutral) and still run into 
"route not found": increase the maxhops paramter by 1 and reset the 
msatoshi factor to 4 again for the next interation.
- Repeat the loop until maxhop reached i.e. 10

Something like this. I'm still fiddling with the details.
Just my two Satoshi...

Michael


On 2021-05-27 23:55, nibnalin wrote:
> Hi all,
> 
> I've been reading through the c-lightning codebase over the past
> couple weeks (great comments and explanations throughout the codebase,
> by the way!) and ran into this FIXME:
> https://github.com/ElementsProject/lightning/blob/master/gossipd/routing.c#L710
> 
> I was wondering if there is any past discussion of how a solution
> could work, or what possible ways to work with it might be. In
> general, I'm curious how routing biases or other changes such as this
> one are evaluated for their utility. I implemented a pretty simple
> bias as a possible draft here:
> https://github.com/nalinbhardwaj/lightning/commit/2ef2f7822a874dbe42e311e8787a28d5860452b4.
> Curious if anyone has any thoughts on it. :) I'm not sure how I can
> fine-tune it to be useful in real settings.
> 
> Besides this particular task, curious if anyone has any suggestions
> for other changes to work on to get a better understanding of
> lightning network.
> 
> Thanks!