Hey folks, I've been looking into how the Lightning Network usually operates, especially regarding the private balances of channels and the asymmetry in the market. I'm trying to get a better handle on the limitations that come with the current implementations and the protocol itself.
It's kind of interesting how the announcements of channel updates reveal a lot of info like strength, CLTV deltas, and fees, but the liquidity focused in channels stays pretty much private. This has led to route construction relying a lot on statistical assumptions and historical performance, rather than solid knowledge.
While I'm digging into this, there's a question that's been bothering me about lightning inference.
I'm curious, when it comes to picking routes, how do current implementations like Core Lightning figure out or estimate the outbound liquidity that's actually available?
I'd really appreciate any insights from anyone here.
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.
From running nodes and watching payments, the biggest facepalm is when people assume a single failure means a channel is bad. Lightning is more like driving in a city... sometimes the road is fine, there's just a delivery truck blocking it for 30 seconds. Good pathfinding is like trying a different street or come back later, not "this road is dead to me forever."
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.