Yeah, that's basically the annoying truth of Lightning routing, nobody deduces the real directional liquidity in any clean, deterministic way, because the balances aren't gossiped. What you get from gossip is the channel's total capacity and the policy bits (fees, CLTV delta, HTLC limits, disabled flags, etc.). So Core Lightning (and the others) start with a map where every channel's capacity is only an upper bound, then they do pathfinding with heuristics.
The real learning happens the brutal way, like when you try a route, and when it fails you get a failure back that lets the sender update its view. A failure on a given hop at amount X effectively tells you "that edge probably can't push X right now", so the node will penalize it and retry with a different path (or a smaller split if you're using MPP). After enough attempts, you end up with a probabilistic "this edge tends to work up to about here" mental model inside the payer, but it's still frail because liquidity moves constantly and some failures are ambiguous by design.
Now I get the gist clearer. Thanks alot.
I also have a question from your response. Agreeing failure messages with intention are with ambiguity, and understanding liquidity changes so quick, I want to know how present implementations make decisions on the penalizing of a channel aggressively where there's unsuccessful attempt, and in what way can there be avoidance of excess penalizing channels that are unsuccessful for reasons of non-liquidity?
Would be glad too if you have answer(s) to my question. Thanks alot.
Well, seems like the moderators deleted four of my posts yesterday (including the one you quoted), not sure why because there wasn't a reason given...
Anyway,
Implementations generally don't do a hard blacklist off one miss, because they can't prove why it missed. What they do instead is keep a rolling score/probability for channels (often per direction, and in some cases implicitly per amount range), and then nudge that score down when a payment fails and nudge it back up when a payment succeeds. The penalty is usually time-weighted and decays, so a channel that had a bad five minutes doesn't get treated like it's cursed forever.
Some failures are "hard truth" and don't deserve much ambiguity handling. Other failures are "probably transient" (temporary channel failure, node overload, HTLC limit stuff, random flakiness), and those typically get a short cooldown penalty rather than a long ban. The really ambiguous ones are treated gently on purpose, so you might avoid that edge for the next attempt or two, but you don't ruin its reputation for the rest of the day. And when you do find a route that works, most routers "forgive" quickly, because success is the best signal you can get in a system where liquidity shifts under your feet.
