Please discuss: Phoenix channels capacity \ stacker news ~bitcoin

Please discuss: Phoenix channels capacity

4901 sats \ 20 comments \ @DarthCoin 5 Jun bitcoin

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

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

10 sats \ 3 replies \ @DarthCoin OP 6 Jun

And I'm not sure why it's not attempting to create a new channel

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.

0 sats \ 2 replies \ @ekzyis 6 Jun

I really want to find out the logic of this.

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

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.

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!

0 sats \ 0 replies \ @ekzyis 6 Jun

lol, nice and patient answers by t-bast in this issue

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.

0 sats \ 0 replies \ @DarthCoin OP 6 Jun

Exactly, is not even 1%. I was surprised to see that too.

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.

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.

A channel is created each time an incoming payment isn't able to "fit" into your existing channels. I disabled that option deliberately, to test this scenario: refill at maximum the existing channels.

But even then a channel that still shows 10000 sats available to receive and is not receiving is weird.

0 sats \ 5 replies \ @ekzyis 6 Jun

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.

You can find more info about this in the FAQ: https://phoenix.acinq.co/faq#how-much-can-i-receive-with-my-existing-channels

-- 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?

0 sats \ 3 replies \ @ekzyis 6 Jun

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

0 sats \ 2 replies \ @DarthCoin OP 6 Jun

Better say when eltoo is implemented and we get rid of all these "reserves".

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.

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...

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.

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.