Yes, good article. But what Shinobi forgot to talk about are ... force closed channesl. In a liquidity marketplace where you have to set a specific CLTV time to lock the funds in a contract, you DO NOT have also an option to KEEP that channel open.
So you are in a even more deep shit: you lock your funds in a larger CLTV, but you got the channel force closed and now you are waiting a longer time to get the funds back.
This doesn't make any sense. LN devs must change or add a new feature that for these specific channels, also imply that will not happen a force close BEFORE that CLTV time.
reply
I thought that the liquidity seller can't force-close the channel before the lease ends? Have I misunderstood something? And the liquidity buyer can force close the channel at any point, completely skipping the CLTV restriction.
reply
CLTV is only about lock the funds until a certain block in case of a force close. But that do not enforce to keep the channel open.
reply
Doesn't the CLTV only lock the funds of the liquidity seller, but not the funds of the buyer, in case the seller force-closes the channel? And if the buyer force-closes, both the seller and the buyer get their funds back near-instantly, after the dispute period, right?
reply
That channel will move funds from one side to another, meanwhile is doing routing. So in case of a force close or cooperative close, each side will get his funds that had in the moment of closure on his side.
The funds are locked until the grace period is reached, for both parties, not just one.
reply
Ah. Sorry, I wasn't sure how it worked exactly. Thx for explaining it! I wonder why the funds are locked at all in case of a cooperative close, and why they are locked for the buyer too in case of a forced close.
reply
Good article, but I felt left hanging at the end. There was no specific proposal to address the problem at the protocol level. Perhaps it's my technical ignorance, but is there an obvious protocol fix? Also, the free market solution, as @tomlaies suggests, may solve this issue over time.
reply
There are multiple protocols already in use to alleviate the problem, but none of them completely fix it. Some examples are:
  1. Liquidity ads. They allow people with excess capital to lend it as inbound liquidity to others who need it.
  2. Opening a channel to someone else and using peerswap to swap the channel funds to the other side, creating inbound liquidity for you.
  3. Hosted channels allow someone else to open channels to you without paying on-chain fees or having to commit capital, eliminating the cost of opening a channel to you. Note that you have to trust the channel opener to not exit scam you, though if they do you have cryptographic proof of it.
You can also create inbound liquidity by just making payments over LN.
reply
Interesting article. In the end, I think, the Lightning network will improve, software will get more stable and resilient and liquidity will rise with more big players coming on the market and Moscow time rising.
reply
A nice article. I say we wait with implementing liquidity ads in the protocol until centralized actors become a problem, if ever.
reply
Liquidity ads are already implemented though. And IMO it's a good thing.
reply