<p>It appears that there is an issue in LND 0.16.2:</p>
<p><a href="https://github.com/lightningnetwork/lnd/issues/7682" rel="nofollow noreferrer">https://github.com/lightningnetwork/lnd/issues/7682</a></p>
<p>It should be fixed in 0.16.3.</p>
<p>BTW, pro tip for routing node operators running LND 0.16.2: Regularly (e.g. once a day) look at your pending HTLCs. If one will expire before your next check, disconnect the peer of the affected channel with <code>lncli disconnect</code>. This should prevent expiry, see <a href="https://github.com/lightningnetwork/lnd/issues/7706" rel="nofollow noreferrer">this issue</a> for more info.</p>

CC BY-SA 4.0
2023-05-28T19:11:56.233Z
2023-05-28T19:37:23.830Z
2023-05-28T19:37:23.830Z
Andreas
<p>According to <a href="https://massmux.substack.com/p/why-i-see-many-force-close-on-my" rel="nofollow noreferrer">https://massmux.substack.com/p/why-i-see-many-force-close-on-my</a> force closes would happen automatically when there is an expired HTLC:</p>
<blockquote>
<p>Most forced close are due to expired HTLC. A transaction tries to go
through your node, ends up in pending status, your node goes offline,
after the HTLC expires (please see below the default hours for each
implementation) the channel goes into force close. More precisely:</p>
<p>LND has by default 40</p>
<p>CLN has by default 34</p>
<p>Eclair by default 144</p>
</blockquote>
<p>so I believe you have this theory:</p>
<blockquote>
<p>The two transactions seem to be related in the sense that the expired HTLC was caused by the force closure.</p>
</blockquote>
<p>backwards, the expired HTLC likely caused the automatic force closure as per the default settings in the relevant lightning implementation.</p>
<p>HTLC relay failure leading to node downtime seems to be the cause, but it is hard to say what specifically about your node setup and channels may have been vulnerable to this situation.</p>
<p>Also like you mentioned, it is possible the remote channel was misbehaving in some way. This is why until you can be certain that you are avoiding all related vulnerabilities you should not open channels with lots of unknown people especially not with questionable reputation.</p>
<p>Edit:</p>
<p>Also relevant from documentation:
<a href="https://i.sstatic.net/4c7DL.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/4c7DL.png" alt="HTLC Docs" /></a> Source: <a href="https://docs.lightning.engineering/the-lightning-network/multihop-payments/hash-time-lock-contract-htlc#3-a-htlc-is-consolidated" rel="nofollow noreferrer">HTLC Consolidated</a></p>

CC BY-SA 4.0
2023-05-20T07:55:40.093Z
2023-05-20T21:53:42.663Z
2023-05-20T21:53:42.663Z
Poseidon
<p>After roughly a month of mostly smooth operation <a href="https://mempool.space/lightning/node/0315375788cca20f15f32ceaac237d89c656282a573b8aca775eaa9bc2054cf06f" rel="nofollow noreferrer">a lightning node</a> (LND 0.16.2-beta) automatically initiated a force closure of a channel. Two days later an expired HTLC was settled on-chain. In both instances, high fees (~2-3 times the going rate) were automatically paid from the on-chain wallet of the node. Everything happened without any user intervention whatsoever. Here are the two transactions:</p>
<p><a href="https://mempool.space/tx/71c18287c075bf3eb9a5083b98701faa87071266e5f0fe33577885fbb1180901" rel="nofollow noreferrer">https://mempool.space/tx/71c18287c075bf3eb9a5083b98701faa87071266e5f0fe33577885fbb1180901</a>
<a href="https://mempool.space/tx/2730193b26c2c2be70d20bb1e3f0e0d4eefed5283086320ae2f361af0f58aadf" rel="nofollow noreferrer">https://mempool.space/tx/2730193b26c2c2be70d20bb1e3f0e0d4eefed5283086320ae2f361af0f58aadf</a></p>
<p>The two transactions seem to be related in the sense that the expired HTLC was caused by the force closure.</p>
<p>So, I'm trying to find out what caused the force closure. As far as I know the lightning network protocol is designed to have the bad actors bear the cost of their behavior and make everyone else whole, so I suspect that the node was misbehaving somehow?</p>
<ul>
<li>Could it be a connection issue (the node is only reachable via TOR)?</li>
<li>How can the high fees for force closure/expired HTLC be avoided in the future, is this configurable anywhere?</li>
</ul>
<p>If you need more info (logs, etc.), I'd be happy to ask the operator to provide them.</p>

<lightning-network><lightning-network-daemon><hash-time-locked-contract>
Automatic force closure and on chain settlement of expired HTLC
Andreas
# Automatic force closure and on chain settlement of expired HTLC

(Asked by: username_0 on 2023-05-17)

After roughly a month of mostly smooth operation [a lightning node](https://mempool.space/lightning/node/0315375788cca20f15f32ceaac237d89c656282a573b8aca775eaa9bc2054cf06f) (LND 0.16.2-beta) automatically initiated a force closure of a channel. Two days later an expired HTLC was settled on-chain. In both instances, high fees (~2-3 times the going rate) were automatically paid from the on-chain wallet of the node. Everything happened without any user intervention whatsoever. Here are the two transactions:

<https://mempool.space/tx/71c18287c075bf3eb9a5083b98701faa87071266e5f0fe33577885fbb1180901>
<https://mempool.space/tx/2730193b26c2c2be70d20bb1e3f0e0d4eefed5283086320ae2f361af0f58aadf>

The two transactions seem to be related in the sense that the expired HTLC was caused by the force closure.

So, I'm trying to find out what caused the force closure. As far as I know the lightning network protocol is designed to have the bad actors bear the cost of their behavior and make everyone else whole, so I suspect that the node was misbehaving somehow?

* Could it be a connection issue (the node is only reachable via TOR)?
* How can the high fees for force closure/expired HTLC be avoided in the future, is this configurable anywhere?

If you need more info (logs, etc.), I'd be happy to ask the operator to provide them.

**Tags:** lightning-network, lightning-network-daemon, hash-time-locked-contract


---

## 2 answers

### Answer by username_0 on 2023-05-28. Score: 1 | Accepted answer

It appears that there is an issue in LND 0.16.2:

<https://github.com/lightningnetwork/lnd/issues/7682>

It should be fixed in 0.16.3.

BTW, pro tip for routing node operators running LND 0.16.2: Regularly (e.g. once a day) look at your pending HTLCs. If one will expire before your next check, disconnect the peer of the affected channel with `lncli disconnect`. This should prevent expiry, see [this issue](https://github.com/lightningnetwork/lnd/issues/7706) for more info.


---

### Answer by username_1 on 2023-05-20. Score: 1

According to <https://massmux.substack.com/p/why-i-see-many-force-close-on-my> force closes would happen automatically when there is an expired HTLC:

> Most forced close are due to expired HTLC. A transaction tries to go
> through your node, ends up in pending status, your node goes offline,
> after the HTLC expires (please see below the default hours for each
> implementation) the channel goes into force close. More precisely:
>
> LND has by default 40
>
> CLN has by default 34
>
> Eclair by default 144

so I believe you have this theory:

> The two transactions seem to be related in the sense that the expired HTLC was caused by the force closure.

backwards, the expired HTLC likely caused the automatic force closure as per the default settings in the relevant lightning implementation.

HTLC relay failure leading to node downtime seems to be the cause, but it is hard to say what specifically about your node setup and channels may have been vulnerable to this situation.

Also like you mentioned, it is possible the remote channel was misbehaving in some way. This is why until you can be certain that you are avoiding all related vulnerabilities you should not open channels with lots of unknown people especially not with questionable reputation.

Edit:

Also relevant from documentation:
[![HTLC Docs](https://i.sstatic.net/4c7DL.png)](https://i.sstatic.net/4c7DL.png) Source: [HTLC Consolidated](https://docs.lightning.engineering/the-lightning-network/multihop-payments/hash-time-lock-contract-htlc#3-a-htlc-is-consolidated)


---

