From the linked FAQ:

How much can I receive with my existing channels?

In the channel details page, the app displays the balance and capacity of each channel. For example, you may have a channel with a balance of 5 000 sats and a capacity of 25 000 sats. However that does not mean you can receive 20 000 sats on this channel: its incoming liquidity is smaller than that.
Some of the channel's funds are "locked" as required by the Lightning protocol, for security reasons (mostly to pay the on-chain fees in case of a unilateral close and to maintain a channel reserve on the ACINQ side). The amount locked varies with the on-chain feerate and can be significant.
Another issue are multi-part payments. When you have multiple channels, the sender will not know their respective balances (this is private information), so they will likely not be able to split the payment optimally between your existing channels (unless the sender uses trampoline).
This is why the app cannot display an accurate "receiving balance", and why channels can be created unexpectedly. This is bad UX, but fortunately we know how to fix it. Once Bitcoin supports package relay we will be able to make changes to the Lightning protocol that will let you have a predictable receiving balance.
Do note that you can always choose to disable on-the-fly channels in the application settings. This way, instead of creating new channels, incoming payments that exceed your receiving balance or aren't correctly split will simply fail.
So apparently this gets solved when package relay is implemented
Better say when eltoo is implemented and we get rid of all these "reserves".
reply
Oh, eltoo also solves this because it completely removes the penalty transaction?
I only thought of it as making running LN nodes easier.
reply
eltoo remove / makes easier a lot of things in LN. But also needs some changes on core code in order to be implemented. But yeah instead of looking how to get eltoo faster, people are looking into "another" directions...
reply