I've been thinking about Lightning routing and wanted to throw out an idea for discussion.
Today, routing naturally favors paths with the highest probability of success. In practice, that often means large, well-established routing nodes with large channels. That's great for reliability, but it may also create a long-term bootstrapping problem.
A new routing node can open well-funded channels, but with no forwarding history it's less likely to be selected. Less traffic means less reputation, which leads to even less traffic. Over time, this could reinforce a "rich get richer" effect where the largest routing nodes continue attracting a disproportionate share of payments.
One possible idea is to make routing *slightly* more capacity-aware. Rather than only optimizing for fees and success probability, the pathfinding cost function could include a very small penalty for using channels that are vastly larger than necessary for a payment. The goal wouldn't be to force small payments onto small channels, but to gently encourage better distribution of traffic while preserving reliability.
This could:
• Give newer and medium-sized routing nodes more opportunities to forward payments.
• Help preserve very large channels for payments that actually require them.
• Potentially improve liquidity distribution and long-term network decentralization.
There are obvious tradeoffs. Channel capacity doesn't reveal available liquidity, so any heuristic would need to be conservative and success probability should remain the primary objective. This would need to be evaluated with simulations before it could be considered seriously.
This is just an early thought experiment, not a finished proposal. I'd be interested to hear whether anyone has explored similar routing heuristics in CLN or the broader Lightning ecosystem.
@Matt Corallo Just musing on some ideas. It might be dumb but wanted to tag you anyways.
Psudo code:
```c
for each channel:
cost =
fee_cost +
cltv_cost +
success_probability_cost +
capacity_penalty(payment_amount, channel_capacity)
find_path_with_lowest_cost()
```
Maybe smaller nodes can benefit from all of these zaps on smaller channels instead of routing tiny payments though giant channels just because they're more reliable.
