You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When rebalancing, I find it helpful to break up the amount I wish to rebalance into smaller chunks. In my experience smaller rebalances are more likely to succeed. But sometimes when stars (or channel capacities) align, there is a good route that can handle a multiple of the small chunk amount. In these cases, I want to take advantage of the capacity without beginning path finding de novo.
I propose that some sort of state is read and stored, perhaps optionally, perhaps in a user-specified file, and upon successfully making a rebalance payment, the state gets updated with the route that succeeded. When the next rebalance request comes with the same incoming and outgoing channels, we try the same route that succeeded last time. This can be further generalized to keep a history of successful routes, analyze them carefully, prioritize historically successful channels, etc.
If the route fails this time, prioritize the non-failing channels in the route for future route selection, because the conditional probability that a previously-succeeding channel will be usable for the new attempt given that it just worked for the last attempt is much higher than the probability that any given channel will be usable.
The text was updated successfully, but these errors were encountered:
When rebalancing, I find it helpful to break up the amount I wish to rebalance into smaller chunks. In my experience smaller rebalances are more likely to succeed. But sometimes when stars (or channel capacities) align, there is a good route that can handle a multiple of the small chunk amount. In these cases, I want to take advantage of the capacity without beginning path finding de novo.
I propose that some sort of state is read and stored, perhaps optionally, perhaps in a user-specified file, and upon successfully making a rebalance payment, the state gets updated with the route that succeeded. When the next rebalance request comes with the same incoming and outgoing channels, we try the same route that succeeded last time. This can be further generalized to keep a history of successful routes, analyze them carefully, prioritize historically successful channels, etc.
If the route fails this time, prioritize the non-failing channels in the route for future route selection, because the conditional probability that a previously-succeeding channel will be usable for the new attempt given that it just worked for the last attempt is much higher than the probability that any given channel will be usable.
The text was updated successfully, but these errors were encountered: