RT @homakov: Gotta love how inbound capacity problem of LN gets rediscovered over and over after I highlighted it in 2017. https://t.co/6k6oI8PaKD
Writing off this fatal bug as "bootstrap issue" is like "ok we are selling a dollar for 90c but gonna get profitable with more scale".
It happens fairly regularly that people lose their channel states, and the only way to recover their funds is to wait for channel closure. Yet as fees rise, the probability of channel closure goes down, and the lower the probability that someone will prematurely close their channel to help you out, should you even be able to locate or contact the responsible party. Solution? Custodial services, never run your own node with any significant amount of money.
The inbound capacity problem is just one form of the LN's general liquidity problem. One of the fatal flaws of the LN's design concerns the existence of two powerful incentives. On the one hand, there's very good reason to have as few open channels as possible -- especially in an environment of high and volatile on-chain fees. High on-chain fees increase the costs associated with opening channels, maintaining channels (funds need to be reserved in the "miner's bucket" to allow for their future closure, and when on-chain fees rise, more funds need to be moved into the bucket), and closing channels that are no longer useful (and rededicating those funds to some other channel). On the other hand, you also want your payment routes to be as short as possible. Shorter routes (a) are more likely to exist (the maximum possible payment along a particular route is limited by the hop with the smallest liquidity in the required direction); (b) are easier to find; (c) are very likely to be cheaper to use (because every hop needs to be compensated for locked liquidity); and (d) are much less likely to fail mid-flight. Thus (and again, especially as on-chain fees become significant), your incentive is to only open channels with partners who you're extremely confident will provide the greatest benefit. That means centrally-positioned (within the LN's topology), massively-capitalized, massively-connected, professionally-run, and (inevitably) heavily-regulated "hubs."
I think they’re *absolutely* fatal especially if you were someone who mistakenly imagined that the LN was a “scaling solution” / solution to the problem of high on-chain fees. Both incentives become stronger as on-chain fees rise.
@Capt_Roger_Murdock claims that LN won't function if nodes have only have a few channels each and there are many hops (it's a "fatal" flaw).
Is that true, or is that an exaggeration? What is the minimum number of channels and the maximum number of hops that is necessary for LN to function? How are those numbers determined?
LN with an accessible base layer is a good thing and is useful for a certain class of payments (frequent micro-payments). The problem is choking out your base layer to push people onto it and expecting everyone to use it for all transactions.
My thoughts are it's a problem with a small sized network. The illustrations show only 1 or a few channels per node. My own node has recieved a factor of 10 in inbound capacity to my outgoing capacity from some hub type nodes with a lot of funding. I imagine as the network grows and users have more than 1 channel the odds of finding a route increase.