ACINQ
LN transactions stuck as PENDING for days, channel closure incomplete
Eclair wallet mainnet, v0.3.4. Tried opening a channel to ACINQ, it opened fine but no payments were working. After a dozen attempts i had half of them stuck in PENDING state and the rest failing for various reasons. I waited for a good portion of a day, then initiated channel closure.
The channel closed unilaterally, and a day later the bulk of the funds got returned. Over the same time all but two of the transactions went to a failed state.
However, the remaining two transactions and the rest of the funds are still pending and missing two days later. This strikes me as an invalid behaviour, or at least as something odd.
Another peculiarity is that trying to view the raw channel data gives out "Loading channel data, hold on..." indefinitely.
Prior to that i had whatever version was on Google before the 0.3.4, it had a channel to ACINQ open and worked fine for a while. Then i closed the (now exhausted) channel, some time later updated the app and opened the new one as described above.
It also strikes me as odd that the first time i had almost 100% success payment rate and the second time i had less than 0% success rate given the same conditions and hours in-between.
So, is this something that is fixable on my end, or what should i provide to help with debugging?
Funding transaction is bc699b95362cccef1bd303f9ba7bd66cd3f677a181e278c15aeaf45ad5ea8276
Channel id reported in the channel details: 7682ead55af4ea5ac178e281a177f6d36cd67bbaf903d31befcc2c36959b69bc
It also reports 3 inflight HTLCs.
One more payment just moved into the failed state 10 minutes ago, after being stuck for a total of 2 days, 21 hours. At the same time a commitment transaction was broadcast spending the part of the unilateral closure output corresponding to it (some action on your side, pm47?).
And a few minutes later the app got stuck for about a minute in a loop of "payment failed after zero attempts" popping up at a rate of several times a second, for that payment which was already marked as failed.
After a first quick check, I don't see anything abnormal. Only one output of the commitment tx hasn't been claimed (for 132015 sat), probably because it has not yet expired (I believe it will at block 528235). When this output is claimed, the channel will move to CLOSED.
Can you share the paymentHash for payments that are still in PENDING state?
As for why all payments fail, were you trying to pay a specific merchant/service? It is possible that they may have been unresponsive and never fulfilled htlcs; in that case neither you nor us can do anything about it except wait for the pending payments to expire. If this is the case you shouldn't force close the channel, it costs you money for nothing: instead you should wait for the htlcs to fail in some downstream channel (expiry are decreasing as you move closer to the destination), and nodes will then fail the payments.
One more payment just moved into the failed state 10 minutes ago, after being stuck for a total of 2 days, 21 hours. At the same time a commitment transaction was broadcast spending the part of the unilateral closure output corresponding to it (some action on your side, pm47?).
Nope, didn't do anything, one of the payments expired at block=527913 (an hour ago)
And a few minutes later the app got stuck for about a minute in a loop of "payment failed after zero attempts" popping up at a rate of several times a second, for that payment which was already marked as failed.
Hmm, this looks like a bug in the android UI, will look into it
Can you share the paymentHash for payments that are still in PENDING state?
The remaining one is 32d37e3c9b77e9929c7ad838d1e8cb90571d2c5afb78d861ec6d9a6e49549ebe, which is for satoshis.place.
Other ones were for it too, and two more were for Bitrefill. All of the destinations worked fine before the update and channel re-creation, with dozens of payments made, so i doubt it's unresponsive recipient that is the problem. The failures were mostly of the something wrong with a channel along the route kind, or something similarly phrased, but i guess it's possible that the whole thing is one big coincidence.
If this is the case you shouldn't force close the channel, it costs you money for nothing: instead you should wait for the htlcs to fail in some downstream channel (expiry are decreasing as you move closer to the destination), and nodes will then fail the payments.
Well, the UI can definitely stand some improvements, i.e. showing the expiration times that you mentioned later. As it is now there is just an indefinite PENDING that you have no idea what to do with, which is likely to prompt people into smashing random buttons, reinstalling the app or doing other stupid things.
At a minimum adding a note about it to the FAQ could be a good idea.
Hmm, this looks like a bug in the android UI, will look into it
Having had the app open for a while longer it happened again a few times, and it appears to happen the moment a new block is mined.
Follow-up: All the funds were eventually recovered after a few more days of waiting (by around Jun 21st), and the channel disappeared from the list.
After that i tried opening a new one then paying, and things worked fine.
I've a similar "Pending" transaction issue. It's in that state for days. Mainnet, 0.3.5.
At the same time, I saw I have a channel in a red state, don't remember what it was called (maybe error?), and slightly blinking every second, as if it was retrying something. That channel changed to "closing uncooperative" today. I didn't initiate that, so maybe the wallet noticed that this channel is bad?
I have a similar problem. I attempted to pay at satoshis.place, which has 10 min expiry. It's already timed-out (about 15 min since then) and still in pending state.
Shouldn't the transaction abort after expiry? Any plans to add a button to abort it manually?
I checked today and it finally failed. It's resolved for me in this specific case, I just hope the timeout will be fixed.
@Kixunil the request timeout and payment timeout are two separate things:
-
the request timeout is set by the merchant (here satoshis.place), it just means that past this time, the merchant will refuse an incoming payment corresponding to this request
-
the payment timeout (the T in hTlc) is an integral part of how lightning works. Each hop in the route adds a timeout that they chose depending on security considerations, and the resulting timeout as seen from the sender will be the sum of all those timeouts.
Your payment failed when the latter timeout expired.
Any plans to add a button to abort it manually?
We can't, the chain of timeouts is what guarantees intermediate nodes that they can trustlessly forward payments. For more info, take a look at these slides (starting at slide 36).
Oh, I see, thanks! I wonder whether there is a way to make it less confusing to the user.
What exactly is the point when the request times out? If the user doesn't connect to the merchant? If the channel with the merchant doesn't update to allow him pulling money by disclosing R?