Nostr is kinda like the universe. It's not a bowl.
View quoted note →
OceanSlim
oceanslim@happytavern.oslim.dev
npub1zmc6...7f60
Pro Gun. Anti War. Working on hyperbitcoinization with Jan3. Hardware enthusiest. Node runner. Live your life in service to others. #nostr only since Block 775261. Father of 2.
Building freedom tech: https://github.com/0ceanslim/
Contact: https://oslim.dev/contact
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.
The problem with lightning...
"I want to help grow lightning"
"minimum channel size 10m sats"
https://cyberdyne.sh/
For my European frens. GA is HOT and WET (106 F)


If you don't own Master Chief Collection, wishlist it on steam and wait for a sale. It goes to $10 on every steam sale. For $10, this MCC is easily the best value per dollar spent in all of gaming. It's like 6 incredible games all in one nice package for $10...
The next 40 days will be quite eventful. Clocks to watch :eyes:
BIP110.com
ecash.com
:blobpopcorn_sm:
Be your own hosting provider. It's not that hard.
View quoted note →
@npub142gz...jufs there should be some better bots now