(Payment stuck) Issue with Phoenix wallet? \ stacker news ~bitcoin

pull down to refresh

(Payment stuck) Issue with Phoenix wallet?

419 sats \ 11 comments \ @aliceandthewonderland 10 Jan bitcoin_support

I created an invoice for approximately 350,000 sats in my Phoenix wallet after confirming that my inbound liquidity was around 470,000. I then wrapped the invoice with an LN proxy Hodl invoice and initiated a payment from Strike. The payment status is was stuck as “initiated.”

When I checked my Phoenix wallet again, I noticed that my inbound liquidity had suddenly dropped from 470,000 to 250,000. I had previously purchased inbound liquidity and resized the channel, and it hasn’t even been a year since then. I suspect that It seems the unexpected reduction in channel size caused the 350,000 sats to getting stuck during the payment process(?)

Fortunately, I received my funds back from Strike (possibly due to the HTLC being refunded). However, based on the situation described above, I’m wondering: Could the issue have been caused by LNproxy being unable to pay my original invoice due to the sudden reduction in channel liquidity on Phoenix, preventing it from obtaining the preimage? Or was the issue on Strike’s end, where they couldn’t pay the Hodl invoice? As far as I know, Phoenix wallet’s default Bolt 11 invoice expiration is about a week, so why did I receive my funds back so quickly?

Or perhaps none of the above, and I’ve misunderstood the situation entirely?

5,000 sats paid

aliceandthewonderland's bounties

view all past bounties

158 sats \ 0 replies \ @endothermicdev 10 Jan

Does LNproxy support Multi Path Payments (MPP?) If strike split this payment, perhaps a first part of the payment made it to you node (220K) and it was waiting on another 130k htlc? That would cause an inbound liquidity drop, and you node would refuse to settle it because it doesn't satisfy the full invoice.

Is your inbound liquidity still reduced?

71 sats \ 5 replies \ @OT 10 Jan

I think you paid an onchain TX. Phoenix moved to a new model in 2023 when they introduced splicing.

https://acinq.co/blog/phoenix-splicing-update

I have been caught out on this without realizing that my channel size was significantly reduced after paying an onchain TX.

It could also have been that if you didn't open the Phoenix app (did you say for a year?!) the hold invoice may never have resolved.

That's what I think happened.

21 sats \ 2 replies \ @aliceandthewonderland OP 10 Jan

I think I wasn’t clear enough in my explanation—my apologies. When I attempted to pay sats to the Hodl invoice generated by LN Proxy through Strike, the payment didn’t go through immediately. Instead, Strike displayed the status as “payment initiated” for about 40 minutes. Concerned about the delay, I checked my Phoenix wallet and noticed that my inbound channel liquidity had suddenly dropped from 470,000 to 250,000 sats. This was why I initially thought that LN Proxy’s inability to pay my Phoenix invoice because of liquidity issue and obtain the preimage led to the Strike payment being stuck in limbo.

I use my Phoenix wallet almost daily, and I had specifically checked my inbound liquidity before generating the invoice to avoid any splice-in fees. This makes me wonder if this issue might have had nothing to do with an on-chain transaction, as there were no on-chain transactions between Strike, LN Proxy, and my Phoenix wallet.

1021 sats \ 1 reply \ @OT 10 Jan

Have a look in your Phoenix wallet > settings > payment channels. Have a look at the Funding TX and see if it spliced out on that LN payment.

I have used hold invoices on Phoenix before so it shouldn't be a problem with them. I haven't used LN Proxy, maybe something happened there that triggered the splice out.

0 sats \ 0 replies \ @aliceandthewonderland OP 11 Jan

Have a look in your Phoenix wallet > settings > payment channels. Have a look at the Funding TX and see if it spliced out on that LN payment.

Yep, you were right, I did splice out some funds, and it led to dropping channel size. Thanks it helped me a lot to study.

13 sats \ 0 replies \ @nym 10 Jan

That sounds likely.

0 sats \ 0 replies \ @DarthCoin 10 Jan

This is most likely. I saw this case once.

134 sats \ 0 replies \ @k00b 10 Jan

Lnproxy wouldn’t have initiated the payment to you if Strike didn’t pay the wrapped invoice, so assuming you saw evidence of a payment in Phoenix, we can rule out strike. It’s unclear from your post how long the payment was stuck, but lnproxy (if it didn’t experience an unexpected problem which given the code I read 6 months ago would cause it to exit and required manual recovery) would’ve released the held payment once it knew the payment failed. It’s possible that ACINQ was holding the payment from lnproxy, trying to splice in liquidity to your channel and that took awhile to fail.

26 sats \ 0 replies \ @ChrisS 10 Jan

It sounds like strike tried to make the payment but couldn’t find a suitable route because you didn’t have enough inbound liquidity(or another unknown reason). Not sure why phoenix showed 2 different numbers but if it was in fact on 250k sats then the 350k sats payment to your node would always fail.

5000 sats \ 1 reply \ @e0ce06e368 10 Jan

Phoenix wallet operates on a dynamic channel model, meaning it automatically manages liquidity in the background. So, the sudden drop in your inbound liquidity (from 470k to 250k sats) could have been due to Phoenix closing and reopening channels to manage fees or balance liquidity. This isn’t unusual, but it can catch you off guard if you're not expecting it.

Now, wrapping your Phoenix invoice with an LN proxy Hodl invoice adds another layer of complexity. Hodl invoices are tricky because the payment isn't settled until the preimage is released. If Phoenix had less inbound liquidity when LNproxy tried to forward the payment, it could have caused the transaction to get stuck. LNproxy might not have been able to fulfill the payment due to Phoenix’s reduced capacity, causing the HTLC to timeout and triggering the refund.

As for why Strike refunded you so quickly, Hodl invoices have their own timeout settings, and maybe LNproxy or Strike has shorter HTLC timeouts than Phoenix’s invoice expiry. So, even though Phoenix invoices default to a week, the payment route might’ve failed earlier due to one of those timeouts.

Could it have been Strike’s issue? Maybe. Strike sometimes struggles with larger Lightning payments depending on routing and liquidity. But given the liquidity drop on Phoenix, it’s more likely the issue started there.

To avoid this in the future;

Monitor your Phoenix liquidity before large payments, as it can change without notice.

Avid wrapping invoices with a Hodl invoice if the payment is time-sensitive or large.

Split large payments into smaller ones to reduce the risk of getting stuck.

But honestly, Lightning’s still a work in progress, and stuff like this can happen.

0 sats \ 0 replies \ @aliceandthewonderland OP 11 Jan

If Phoenix had less inbound liquidity when LNproxy tried to forward the payment, it could have caused the transaction to get stuck. LNproxy might not have been able to fulfill the payment due to Phoenix’s reduced capacity, causing the HTLC to timeout and triggering the refund.

I exported the Phoenix wallet log from the event on Jan 10, 2025, UTC, to see whether it attempted to process the payments. The log indicates that it indeed tried to execute payments through MPP for amounts of 175,000 sats and 2 of 87,500 sats. But it appears that the LN proxy failed to complete these transactions, resulting in keep Phoenix purging incoming payments multiple times like image below, which ultimately led to the rollback of the transactions and the subsequent release of the HTLC by Strike. Indeed it seems you are right. Not sure if this is accurate, but this is my reasonable scenario thus far.

So, the sudden drop in your inbound liquidity (from 470k to 250k sats) could have been due to Phoenix closing and reopening channels to manage fees or balance liquidity. This isn’t unusual, but it can catch you off guard if you're not expecting it.

as mentioned by @OT, I found out that I did splice out some funds to on-chain, which explains the sudden drop in inbound liquidity.