So, I was playing around with Phoenix. Testing all features, logic, displaying messages etc.
I like to see each LN app using real LN channels, how much is capable to refill or empty those channels, trying to understand the logic behind.
I was doing some tests, trying to refill some channels.
I thought that Phoenix is using MPP and could receive a payment into all channels, distributing the sats in the best way could find a way.
But is not.
Not just that is not spliting the payment in multiple shards and refill all channels available but is not even able to receive a decent amount in each, if I just sent a smaller payment.
According to the channels list I have these 4 channels.


So according to this list, I should have:
chan A can receive: 10370 sats
chan B can receive 9620 sats
chan B can receive 10328 sats
chan D can receive 10435 sats
I also checked in channels details for how much is the channel reserve and I saw that is a surprisingly only 546 sats reserve for each channel! How is possible only that?
But OK, even if I would deduct that reserve, I should be able to send at least 10000 sats for those 3 channels and 9000 sats for the other one. Not talking about sending the total of 40753 sats that it should be available to receive.
Please, can you explain me how is the logic of these channels?
I am trying to use the maximum space in these channels but the payment always fail now, whatever amount I use to pay.
All channels are active and well.
I would like to hear your opinions / explanations. Please, only those that know what is about. Please do not come with solutions or suggestions "use x wallet". I just want to understand how Phoenix could use efficiently the space in the channels and if it can be improved in some way.
This is also posted on their github discussion page
https://github.com/ACINQ/phoenix/discussions/365
related
414 sats \ 5 replies \ @TonyGiorgio 6 Jun
This is because the sender is unaware of your channel balances and how much to split up their payments properly, since MPP is something the sender does.
I'm a bit unsure why the sender wouldn't eventually find the right split, but perhaps there's a time out issue here. And I'm not sure why it's not attempting to create a new channel instead of trying to fit down the existing ones. Perhaps I misread something or I'm not familar with how you are testing this.
https://github.com/ACINQ/phoenix/issues/155
reply
10 sats \ 3 replies \ @DarthCoin OP 6 Jun
Because deliberately I disabled that option in settings (open channels on the fly).
I wanted to test exactly this, how to refill at maximum the existing channels. I do not want more channels. Or at least to find out that max limit until I can refill it.
I was sending from many different sources not just one dump wallet that doesn't do MPP. I even tried manually to construct an MPP:
What am I afraid of is that Phoenix is really pushing users to open more channels on the fly and charge that 3000 sats fee for each, instead of using efficiently the space in existing channels.
I tried also with smaller parts, just to refill one by one the channels. and didn't work.
I really want to find out the logic of this.
reply
0 sats \ 2 replies \ @ekzyis 6 Jun
If I understood @TonyGiorgio correctly, it's because Phoenix is a private node and thus senders aren't aware of your channels?
I might be wrong though
reply
100 sats \ 1 reply \ @DarthCoin OP 6 Jun
Yes that's right, is a private node using route hints and trampoline channels.
That's not a real issue here.
The issue is that I do not understand why a channel with a capacity of 62k sats and with almost 10k sats still available to receive, can't receive a damn payment of 1k sats.
The only explanation I could see in this are the commit_fees, that vary depending on the onchain fees. But at least the UI of the app should inform better the user, displaying a REAL "can receive" amount.
Right now is really confusing and many users will just open a shit ton of small channels instead of refilling better those existing ones.
reply
0 sats \ 0 replies \ @ekzyis 6 Jun
Ah, I see. I think I had similar experience in the past where I was confused because I thought it should fit.
Thanks for the post!
reply
0 sats \ 0 replies \ @ekzyis 6 Jun
lol, nice and patient answers by t-bast in this issue
reply
21 sats \ 1 reply \ @OriginalSize 6 Jun
Obviously the 546 sats reserve isn't correct and they want to avoid force closes. I feel like what you've done is discover the true reserve amount behind the scenes.
reply
0 sats \ 0 replies \ @DarthCoin OP 6 Jun
Exactly, is not even 1%. I was surprised to see that too.
reply
21 sats \ 1 reply \ @leo 6 Jun
A channel is created each time an incoming payment isn't able to "fit" into your existing channels. Phoenix will add a bit of "remote" capacity on top of it, but from the looks of it, you have over time received four payments in the range of 25k to 60k at a time when your remote balance was less than that.
I agree that Phoenix' practice feels highly wasteful in terms of on-chain fees, but it might be very efficient for them in terms of capital efficiency. I don't know if their approach of multiple small channels has an effect on payment success rates, but quite possibly not.
What I'd love to see is an option in Phoenix to select how much incoming capacity you'd like to have, and whenever you receive the next incoming payment, Phoenix would create the channel of the size you desire, and charge you for it.
In the meantime, you can create such a girthy channel for yourself by sending a large on-chain or off-chain payment to yourself in a single chunk, then send sats back out over the Lightning Network.
reply
1 sat \ 0 replies \ @DarthCoin OP 6 Jun
Yes I was testing with small channels deliberately. Yes I know that is better to use larger channels. Yes I know that are also commit_fees involved in the limit of a channel.
But even then a channel that still shows 10000 sats available to receive and is not receiving is weird.
reply
0 sats \ 5 replies \ @ekzyis 6 Jun
Posting answer from dpad85 here so we can discuss here, too:
-- https://github.com/ACINQ/phoenix/discussions/365#discussioncomment-6101023
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?
reply
0 sats \ 3 replies \ @ekzyis 6 Jun
From the linked FAQ:
So apparently this gets solved when package relay is implemented
reply
0 sats \ 2 replies \ @DarthCoin OP 6 Jun
Better say when eltoo is implemented and we get rid of all these "reserves".
reply
0 sats \ 1 reply \ @ekzyis 6 Jun
Oh, eltoo also solves this because it completely removes the penalty transaction?
I only thought of it as making running LN nodes easier.
reply
10 sats \ 0 replies \ @DarthCoin OP 6 Jun
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
0 sats \ 0 replies \ @DarthCoin OP 6 Jun
Yes, I replied to him. So were the commit fees that had a suspicion about but wasn't sure.
reply
0 sats \ 0 replies \ @dgy 6 Jun
Yes I can confirm that refilling channels in Phoenix without creating new channels is tricky.
The "open channels on the fly" I have disabled at the moment because of that.
Interestingly I have currently a channel with zero balance on my side. So these channels seem to be managed. It appears that if they need capacity then they could close such a channels that has collected all capacity on their side or I can used it to get a larger inbound payment.
reply