mirror of
https://github.com/lightningnetwork/lnd.git
synced 2026-08-17 13:06:14 +02:00
18cc7719ac
The published explanation of why served weights hurt lnd was wrong, and it reached the dashboard. It said lnd files a failure as a pair penalty carrying no amount, suppressing a corridor for every payment size. probability_apriori.go:363 returns the unpenalized prior whenever amt < FailAmt, so the estimator gates on amount correctly. A Fable advisor found it by reading the estimator rather than the summary. Its replacement hypothesis was wrong too. Node-level contagion is real -- getNodeProbability folds pair results into a node prior used for all that node's untried channels, which the "761 edges, 761 pairs" check never ruled out -- but disabling it with apriori.weight=1.0 leaves the loss at -0.038 against -0.046. The third guess, staleness, looked decisive and was a confound. Failures from a one-payment server cost lnd +0.000 on 0 of 10 files, but that set holds 232 observations against the stale set's 2,808. A size-matched random subsample of the STALE set gives -0.003. At equal volume stale and fresh are indistinguishable. What survives is volume. Each imported failure blocks one directed edge at or above its amount, and server and consumer draw amounts from the same distribution, so the bounds land where the consumer is about to send. At 232 observations nothing happens; at 2,808 over a 761-edge graph lnd finds its amount blocked almost everywhere and can only route around, onto longer and worse paths. The upstream thesis survives in a sharper form. lnd's estimator does not ignore amounts. Nothing DOWNSTREAM of it can act on an amount bound, because findPath takes the amount as a fixed argument -- so knowing that at least X fails on an edge can only subtract routes, never resize the payment. That is exp-002b's finding from the opposite direction, and the two now converge on one patch instead of two observations. Two further claims are labelled rather than deleted. exp-011's paradigm ceiling is confounded with the optimizer, since every run in this program used engine="gepa" and three lineages converging on one band is evidence about that engine's attractor as much as about the problem; the adjudicating run is specified in the writeup. And the proposer law from exp-010b was fitted to two opposite-sign runs, so it is downgraded to a hypothesis. Also stages params_lnd_no_contagion.json, the weight=1.0 configuration that isolates node-level aggregation, so the contagion control is reproducible. |
||
|---|---|---|
| .. | ||
| exp-001-param-smoke.md | ||
| exp-002-param-run1.md | ||
| exp-002b-bimodal-knob.md | ||
| exp-003-seed-router-vs-lnd.md | ||
| exp-004-code-evolution.md | ||
| exp-004-sim-audit.md | ||
| exp-005-sim-audit.md | ||
| exp-006-breakthrough.md | ||
| exp-007-mix-followup.md | ||
| exp-008-drift-evolution.md | ||
| exp-008-drift1-best-candidate.go | ||
| exp-008-drift1-best-candidate.md | ||
| exp-009-mainnet-validation.md | ||
| exp-010-opus1-best-candidate.go | ||
| exp-010-opus1-best-candidate.md | ||
| exp-010-opusmed1-best-candidate.go | ||
| exp-010-opusmed1-best-candidate.md | ||
| exp-010-split2-best-candidate.go | ||
| exp-010-splitting-pressure.md | ||
| exp-010b-atomic-splitting.md | ||
| exp-010b-atomic1-best-candidate.go | ||
| exp-010b-atomic1-best-candidate.md | ||
| exp-010b-atomicopus1-best-candidate.go | ||
| exp-010b-atomicopus1-best-candidate.md | ||
| exp-011-code-gen2.md | ||
| exp-011-gen2-best-candidate.go | ||
| exp-012-cold-cache.md | ||
| exp-013-hybrid-continuation.md | ||
| exp-013-hybrid1-best-candidate.go | ||
| exp-013-hybrid1-validation.json | ||
| exp-014-traffic-engine.md | ||
| exp-015-churn-ladder.json | ||
| exp-015-churn-ladder.md | ||
| exp-015-hb1-churn-n40.json | ||
| exp-016-atomic1-importer.go | ||
| exp-016-mxc3-importer.go | ||
| exp-016-served-weights.json | ||
| exp-016-served-weights.md | ||