Posting answer from dpad85 here so we can discuss here, too:
Hello,
Phoenix is indeed using MPP but the split won't be optimal in many cases. If the sender is not using trampoline (which is the case with many LN wallets) the payment will likely not be split. The sender does not know about your 4 channels A, B, C, and D.
Also, a channel's incoming capacity is affected by the on-chain feerate. The feerate is currently quite high, and if your channels are small (like in your screenshot) this can lock a substantial portion of your incoming capacity. But that is not wasted space, it guarantees the safety of your channels.
I think we missed that the incoming capacity is affected by the on-chain feerate (leaky abstraction).
Imo, that explains enough why the incoming capacity is lower than expected, even when using trampoline payments.
Does everyone else agree?
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
reply
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
Yes, I replied to him. So were the commit fees that had a suspicion about but wasn't sure.
reply