Commit fa0beaf
committed
Reduce the default default channel bounds half-life
Utilizing the results of probes sent once a minute to a random node
in the network for a random amount (within a reasonable range), we
were able to analyze the accuracy of our resulting success
probability estimation with various PDFs across the historical and
live-bounds models.
For each candidate PDF (as well as other parameters, to be tuned in
the coming commits), we used the `min_zero_implies_no_successes`
fudge factor in `success_probability` as well as a total
probability multiple fudge factor to get both the historical
success model and the a priori model to be neither too optimistic
nor too pessimistic (as measured by the relative log-loss between
succeeding and failing hops in our sample data).
Across the simulation runs, for a given PDF and other parameters,
we nearly always did better with a shorter half-life (even as short
as 1ms, i.e. only learning per-probe rather than across probes).
While this likely makes sense for nodes which do live probing, not
all nodes do, and thus we should avoid over-biasing on the dataset
we have.
While it may make sense to only learn per-payment and not across
payments, I can't fully rationalize this result and thus want to
avoid over-tuning, so here we reduce the half-life from 6 hours to
30 minutes.1 parent 829dd26 commit fa0beaf
1 file changed
+3
-3
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
769 | 769 | | |
770 | 770 | | |
771 | 771 | | |
772 | | - | |
| 772 | + | |
773 | 773 | | |
774 | 774 | | |
775 | 775 | | |
| |||
781 | 781 | | |
782 | 782 | | |
783 | 783 | | |
784 | | - | |
| 784 | + | |
785 | 785 | | |
786 | 786 | | |
787 | 787 | | |
| |||
791 | 791 | | |
792 | 792 | | |
793 | 793 | | |
794 | | - | |
| 794 | + | |
795 | 795 | | |
796 | 796 | | |
797 | 797 | | |
| |||
0 commit comments