HTLCs stuck in limbo for months after force close about lnd HOT 10 CLOSED

1-Level-HTLCs resulting from STATIC_REMOTE_KEY channels cannot be bumped because their signature is static and negotiated during the building up of the htlc. For anchor channels thats not the case, HTLCs have actually zero-fees, and are only provided with sufficient feerate when they are swept.

from lnd.

Yes theoretically, but the peer has not incentives to do so if the channel is already closed. But yeah it's possible and that's why anchors-zero-fee-htlc-tx were introduced I think.

Closing this issue, because thats the general downside of STATIC_REMOTE_KEY channels. No way to bump the fee of the commitment transaction nor the htlc sweeps.

from lnd.

Hi @ppppso, thanks for the report.

It could be that the second stage htlc output values are too low to be swept, e.g. their value is less than what the sweep fee would be, so lnd isn't sweeping until the mempool fees decrease.

If it doesn't majorly impact your operations, could you restart your node and grep for the outpoint of the channel thats closing and see what lnd reports for it?

from lnd.

Thanks for your reply.

It could be that the second stage htlc output values are too low to be swept, e.g. their value is less than what the sweep fee would be, so lnd isn't sweeping until the mempool fees decrease.

The unconfirmed tx is the one that spends directly from the force closing tx. My understanding is that this is the first stage and the sweeper can only sweep the second stage, correct?

If it doesn't majorly impact your operations, could you restart your node and grep for the outpoint of the channel thats closing and see what lnd reports for it?

I'm unable to restart the node at the moment. It's a business critical node and due to its size it takes a long time to start. This is the only occurrence I see right now:

[INF] NTFN: Found input xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:x, spent in yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

from lnd.

The unconfirmed tx is the one that spends directly from the force closing tx. My understanding is that this is the first stage and the sweeper can only sweep the second stage, correct?

Yes that's also my understanding. Once the second stage tx is confirmed and enough blocks are mined for the to_self_delay to be expired the htlc output should be swept by the sweeper(if its economical).

Would it be possible to send the related channel output of lncli pendingchannels to hieblmi (a)(t) lightning.engineering so that we can further investigate?

from lnd.

I'll see if I can do that.

In any case, can you confirm that a pending HTLC in stage one cannot be bumped? The commitment type is STATIC_REMOTE_KEY. I saw in channel.go a comment saying that if it's an anchor commitment then the tx can be resigned (and presumably bumped?), but it's not clear to me what happens if it's not.

Thank you.

from lnd.

Yes I can confirm in that case. Since the second stage htlc tx is tied to spending only the commitment tx(no other inputs can be attached) and the channel doesn't have an anchor this closure can't be fee bumped and has to confirm once the mempool calms. Another way would be to use a fee accelerator to get it confirmed quicker.

Theoretically I think the peers could however sign a new htlc tx with updated fee rate, but afaik that's not implemented yet. But in general new channels should be opened with commitment type 'anchors'.

from lnd.

Is it correct that the fee could theoretically be updated if the htlc is re-signed?

from lnd.

Thanks for the replies.

What about a CPFP tx? Could it be done?

from lnd.

no that's not possible because the First-Level HTLC sends to a P2WSH which is bound to a relative timelock.

See: https://github.com/lightning/bolts/blob/master/03-transactions.md#htlc-timeout-and-htlc-success-transactions

from lnd.