pull down to refresh

Hi! ACINQ/Phoenix dev here.
The general idea is that Phoenix is geared toward use cases that make the most economical sense, as a self-custodial Lightning wallet. It is true that with v2 we have so far made little effort to accomodate use cases that we are not convinced are sustainable at scale. The reason is that there is a very fine line between "doing our best to allow everyone to play" and "actively incentivizing unsustainable usage". This is not at all to say things are frozen the way they are today, it just explains our approach and the order in which we are doing things.
What makes the most economical sense: loading Phoenix from time to time with large (compared to mining fees) amounts, and then spend anytime with any amount. It scales and incentives are aligned for everyone. This is the so-called "Visa use case", except that Phoenix/Lightning arguably does it already better (faster, cheaper, and more privately) than Visa -- a widely underappreciated fact, in our opinion.
Person-to-person micropayments are much more challenging to do in an economically scalable way. What you see as your inbound liquidity is in fact our balance. It is easy to foresee the potential issues when you scale to 1M users. Our starting point was to not take any fee on receive, and not provide any additional liquidity. This causes mining fees to deincentivize receiving tiny payments, which is what you are running into here. We are actively discussing that and already received interesting feedback on various options. Again we're not judging what should or should not be done in principle, just what service we can deliver reliably and sustainably at scale.
LN is supposed to be cheap and stay that way?
Lightning is only cheaper than on-chain, big difference (and also: instant and more private).
Very much appreciate this community work and reasonable arguments. I see your point. The option to buy inbound liqudity would be nice, as A) I would have a way to spendl (adoption here is shit) and B) could solve my issue for micro TXs
reply
But what does not make sense to be is, that when you try to spent (had to do it via onchain sadly), the channel will be spliced out (automatically reduced in size).
reply