routing: track in-flight htlcs in mission control [wip, don't review]#3373
routing: track in-flight htlcs in mission control [wip, don't review]#3373joostjager wants to merge 6 commits into
Conversation
Previously mission control tracked failures on a per node, per channel basis. This commit changes this to tracking on the level of directed node pairs. The goal of moving to this coarser-grained level is to reduce the number of required payment attempts without compromising payment reliability.
This commit updates existing tests to not rely on mission control for pruning of local channels. Information about local channels should already be up to date before path finding starts. If not, the problem should be fixed where bandwidth hints are set up.
joostjager
changed the title
joostjager
added
the
incomplete
joostjager
changed the title
|
This PR needs to be rebased. Most of the code has already been merged. |
|
What of the fate of this PR? |
|
This is a component for prepay probing. If a (min amount) probe get stuck, that route will be avoided for further probes/payments. Its fate depends on how we prioritize this. |
|
Examined this PR again. The only commit that isn't merged yet is The priority of this improvement is not very high at the moment. The 'black hole' event doesn't seem to be a pressing problem, at least not on mainnet. One can also argue whether the approach is right. Especially with MPP (and previously already with hold invoice), an in-flight htlc isn't necessarily bad. Avoiding these channels may actually result in worse routing performance. Closing this PR until there is a better plan and/or more urgency to solve the issue. |
2 participants
This PR is a first step towards avoiding paths that have stuck htlcs on them. Mission control is modified to be aware of initiated but not yet completed payments. Based on that information, the probability estimation can be modified to return lower probabilities for those paths.