So all lightning channels exchange signed transactions each time a channel is used (when creating or fulfilling an htlc for example.) The commitment transaction can be broadcast to chain at any time because it already has the necessary signatures of both parties to make it a valid transaction.
Normally, a node would just hang on to this commitment transaction and wait to use the channel again and that's what happens the vast majority of the time. The trouble comes if your peer goes offline and you want to be able to spend these funds. You can only do this if the transaction is broadcastable. When the feerate spikes, this may no longer be the case unless you and your peer update the tx with a higher feerate - this is normally done cooperatively with both peers online. If they are offline though, you may be better off settling before the feerate gets too out-of-hand and you're stuck with an unspendable channel.
Anchors solve this problem in a nice way, allowing a channel participant to bring their own output to spend a channel's anchor and CPFP here at a higher effective feerate even though their peer may be missing.
The other problem is the time-sensitivity of htlcs. Suppose you're routing a payment; as the deadline approaches for your incoming htlc, you're faced with it becoming unspendable. Meanwhile, the outgoing htlc you offered a peer on another channel can still be claimed by that peer if they receive the preimage. It's not safe to not resolve this timed out htlc because you could be left on the hook for the difference. If your peer is offline, the only way to resolve it unilaterally is to now force close the channel.
I may be missing others cases, but these are two of the prominent issues, and I think anchor channels along with using an increased cltv delta are two of the remedies to consider.
Wow thank you for that detailed answer. I don’t understand most of it but now I can at least start looking it up.
Where does a backend like LDK or an LSP like OLYMPUS come in?
I’ve seen LDK cited as the reason for some force closes. I’ve also had a channel with OLYMPUS through a couple of fee spikes so they must be doing something right.
Seems like one doesn’t have much of a choice when it comes to the backend, but there are plenty of LSPs to choose from.
reply
What can an user do in order to prevent this kind of closure? , is having a balance ⚖️ liquidity a solution?
reply
At least the uptime of the node need to be 100% and reachable.
reply
Amazing response. Thank you for taking the time to explain in depth!
reply