Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
routing: process payment successes in mission control #3372
This PR modifies
A fixed success probability is introduced for node pairs that proved to be successful on the previous payment attempt. This value could be exposed as a parameter in the future.
Furthermore the default a priori success probability (defines the probability for node pairs with no history) is lowered from 95% to a more realistic 60%. This wasn't possible before, because it would discourage longer routes too much. With the newly introduced "success success probability", only long routes consisting of unknown node pairs are avoided.
No database migration is needed, because we persist only the raw payment results and not the interpretation.
Roasbeef left a comment
Only a few minor comments, and some brain storming for possible future directions. Dependent on another PR, so we'll need to wait until that goes in before we can proceed with this one.
Yes, valid concern. Those constants are set to something that looked reasonable to me, but there is no science behind it.
I spend quite some time to produce a test result that would show the benefit of the changes in this pr.
No significant difference unfortunately. Intuitively I'd expect that accounting for successes should show up in the number of attempts needed, but with this test setup it doesn't. I tried with different amounts, but that didn't make much of a difference either.
My current theory is that there are not enough failures to make any improvement in mission control stand out. However, in other circumstances (mainnet, node connected to a bad cluster) it could make a difference. It isn't ideal though that I cannot demonstrate this.
One thing that I did get out of this test is that there apparently isn't a regression with the changes in this pr. Payment performance is about the same as before.
What I didn't test is the difference in performance over time. Because failures decay (and we need to decay them otherwise we may end up with an empty channel set), a mission control based on failures only will slowly forget everything it has seen. The decay speed can be tuned, but it remains a difficult parameter to pick. Success observations as they are introduced in this pr, do not decay. They keep the success probability of the channel high as long as no failure is observed. That means that this part of mission control's memory isn't forgetting. Therefore payment performance after a day (with default mission control half life time) could very well be noticably better for a successes-aware mission control.
To validate that last hypothesis (performance over time), I did the following:
So possibly the behavior over time is where the real win of this PR is.
This commit modifies paymentLifecycle so that it not only feeds failures into mission control, but successes as well. This allows for more accurate probability estimates. Previously, the success probability for a successful pair and a pair with no history was equal. There was no force that pushed towards previously successful routes.
اريد بيانات وحسابات في البنوك المحليه والدولي والعالميه في السبت، ٢٤ أغسطس، ٢٠١٩ ٢:٣٣ ص Olaoluwa Osuntokun <firstname.lastname@example.org> كتب:…
Merged #3372 <#3372> into master. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3372?email_source=notifications&email_token=AHZKIP6SYX2Y5KNBVB7VA2TQGBXU5A5CNFSM4IJIQ6WKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOTHL7OQA#event-2581067584>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHZKIP6YMLJAIRWQIE6ZI3LQGBXU5ANCNFSM4IJIQ6WA> .