<p>Answering from the perspective of the node that triggers the force-close:</p>
<ol>
<li>Outgoing HTLC times out (i.e., peer doesn't settle/fail in time, which can happen if the peer is offline/unreachable)
<ol>
<li>There are plenty of special cases, including bugs, though. One fun example: on a payment A-B-C-... where I'm A, node C drops dead. The HTLC between B and C times out, B force-closes. The force-close transaction doesn't confirm in time (because B doesn't bump the fees), so the HTLC between A and B also runs into a time out and A force-closes the channel.</li>
</ol>
</li>
<li>Bugs like <a href="https://github.com/ElementsProject/lightning/issues/4649" rel="nofollow noreferrer">https://github.com/ElementsProject/lightning/issues/4649</a></li>
<li>Incoming HTLC times out (I don't know the specifics, but I've seen force-closes where my peer's force-close transaction contained an HTLC that my force-close transaction doesn't have)</li>
<li>Peer asks for force-close (recovery mode, &quot;hey, I lost my channel state, please be so kind and broadcast your most recent force-close tx, kthxbye&quot;)</li>
<li>Trivial: You trigger the force-close manually</li>
</ol>

CC BY-SA 4.0
2023-07-20T12:33:13.360Z
Is there a way to upgrade your system, which generally takes time and rarely goes without a hitch, without resulting in a bunch of force closures? Disable all channels? Anything?
Sandwich
CC BY-SA 4.0
2023-07-20T16:04:25.460Z
Usually, a couple of hours of downtime are OK. You can wait until your node doesn't have a pending HTLC to reduce the disk. In the past 5 years only did that for major updates, not simple reboots.
C-Otto
CC BY-SA 4.0
2022-04-04T16:24:49.433Z
2022-04-04T16:30:32.340Z
2022-04-04T16:30:32.340Z
C-Otto
<p>I suspect this depends heavily on the implementation, but maybe someone can shed light on the circumstances that would lead an implementation to force close a channel automatically.</p>
<p><a href="https://stacker.news/items/17752" rel="nofollow noreferrer">A user asked this on stacker.news</a> but I know all the wizards are on here.</p>
<blockquote>
<p>Nobody in the right mind will force close a channel manually, without a reason. We all do that cooperative close, if a peer is still online and we really need to close that channel.</p>
<p>But automated force closing are really frustrating.</p>
<p>Let's make a list here of all situations, considerations, reasons, causes etc that a channel will be automatically force close and also if you know what steps to do to avoid them.</p>
<p>We have many LND nodes with this situation, few CLN and even fewer Eclair nodes.
Possible causes:</p>
<ul>
<li>some incompatibility between LN implementations ?</li>
<li>different CLTV delta settings between peers?</li>
<li>too many HTLC on the fly for long time?</li>
<li>a minimum time a node can be offline?</li>
<li>too many commit changes for a channel in a certain time?</li>
<li>bad reconnectivity?</li>
</ul>
</blockquote>

<lightning-network><lightning-network-daemon><core-lightning><eclair>
Under what conditions would lightning channels be force closed automatically?
k00b
# Under what conditions would lightning channels be force closed automatically?

(Asked by: username_0 on 2022-04-03)

I suspect this depends heavily on the implementation, but maybe someone can shed light on the circumstances that would lead an implementation to force close a channel automatically.

[A user asked this on stacker.news](https://stacker.news/items/17752) but I know all the wizards are on here.

> Nobody in the right mind will force close a channel manually, without a reason. We all do that cooperative close, if a peer is still online and we really need to close that channel.
>
> But automated force closing are really frustrating.
>
> Let's make a list here of all situations, considerations, reasons, causes etc that a channel will be automatically force close and also if you know what steps to do to avoid them.
>
> We have many LND nodes with this situation, few CLN and even fewer Eclair nodes.
> Possible causes:
>
> * some incompatibility between LN implementations ?
> * different CLTV delta settings between peers?
> * too many HTLC on the fly for long time?
> * a minimum time a node can be offline?
> * too many commit changes for a channel in a certain time?
> * bad reconnectivity?

**Tags:** lightning-network, lightning-network-daemon, core-lightning, eclair


---

## 1 answers

### Answer by username_1 on 2022-04-04. Score: 4 | Accepted answer

Answering from the perspective of the node that triggers the force-close:

1. Outgoing HTLC times out (i.e., peer doesn't settle/fail in time, which can happen if the peer is offline/unreachable)
   1. There are plenty of special cases, including bugs, though. One fun example: on a payment A-B-C-... where I'm A, node C drops dead. The HTLC between B and C times out, B force-closes. The force-close transaction doesn't confirm in time (because B doesn't bump the fees), so the HTLC between A and B also runs into a time out and A force-closes the channel.
2. Bugs like <https://github.com/ElementsProject/lightning/issues/4649>
3. Incoming HTLC times out (I don't know the specifics, but I've seen force-closes where my peer's force-close transaction contained an HTLC that my force-close transaction doesn't have)
4. Peer asks for force-close (recovery mode, "hey, I lost my channel state, please be so kind and broadcast your most recent force-close tx, kthxbye")
5. Trivial: You trigger the force-close manually

> **Comments:**
> **username_2**: Is there a way to upgrade your system, which generally takes time and rarely goes without a hitch, without resulting in a bunch of force closures? Disable all channels? Anything?  
> **username_1**: Usually, a couple of hours of downtime are OK. You can wait until your node doesn't have a pending HTLC to reduce the disk. In the past 5 years only did that for major updates, not simple reboots.  

---

