Ok, so I'm running LND v0.16.2-beta and I had this HTLC stuck for days, I'm not sure if it was incoming or outgoing. Anyways, the HTLC was sitting there for days until its expiration height was reached today and I had a force close, here's the tx: https://mempool.space/tx/366eac0f08ab55ebf63320531063b32d8d74443ebd45400deca5f257ab2093dc
So there are a few questions I have about this:
1- Why was this HTLC locked? This peer was not unresponsive and neither was my node, in fact this was a very active peer and I've been routing other payments with it even after this HTLC got stuck. So it's kind of a shame that we had to come to this conclusion, all for 16K sats :(
2- In the output that pays me, a further tx was created, this one. I was like WTF? all this did was to move that output from an P2WKH to a P2TR output. Thank's I guess, but did my node HAD to do this?
HTLC did not resolve in time, must go on chain via Force Close
Force Close outputs are time locked. Non initiator of the close has a time lock of 1 block. Since there's only one htlc in the close, it's probably not yours. The P2TR output is to your wallet.
reply
Yeah my question was more like why did this happen? it's not like my node or this peer were out of communication. Like I said we were communicating fine, even forwarding several other HTLCs. I have like 13 routing events with this peer since Jan 13th. And I saw this stuck HTLC for several days before the force close, I was afraid it was going to happen. It seems more like a bug.
Also by analyzing the structure of the transaction, I can see that my output is the to_remote (unencumbered one). So why the extra transaction, is labeled as a "sweep" by RTL but I was under the impression that only the to_local needed a sweep. So this other tx makes no sense to me.
reply
Ok I did figure out the #2, which is the sweep transaction. It's explained here.
This seems super innefficient though... :\
reply
Could this be one of those hodl invoices?
reply