<p>If it's a mutual close, the HTLC will be resolved prior to closing of the channel. If the close is unilateral, then yes the HTLC which is below the <code>dust_limit_satoshi</code> cannot be resolved. When you are adding HTLC below the <code>dust_limit_satoshi</code> there is some trust element involved and hence we deduct the HTLC amount from our "balance" as a fee in the commitment transaction.</p>

<p>The bigger question at play is asking yourself why you are closing the channel unilaterally. There may be a number of reasons like peer is unresponsive, peer has fallen behind, or worse peer is trying to cheat. In such cases, protecting your balance in the channel is much more important than a couple of satoshis that might have been added below the dust limit.</p>

<p>Moreover, the fees that you will pay for unilateral close will also be higher than a mutual close. If the commitment transaction had a bunch of HTLCs, the fees from the transaction size will be much higher than the couple of satoshis that you might have added in form of HTLC that you have forwarded. So, when you broadcast the commitment transaction for the unilateral close containing HTLCs below dust limit, you will lose that much amount if you have forwarded the HTLC. Your peer will lose the HTLC amount (below dust) if it was the one that had forwarded the HTLC.</p>

CC BY-SA 4.0
2019-11-16T05:01:42.100Z
2019-11-16T05:01:42.100Z
Ugam Kamat
<p>I just tried to chase that edge case down in the BOLTs. We find at <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection" rel="nofollow noreferrer">https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection</a></p>

<blockquote>
  <p>if an HTLC it has fulfilled is in either node's current commitment transaction, AND is past this fulfillment deadline: MUST fail the channel.</p>
</blockquote>

<p>While the htlc below the dust limit is not an output in the commitment tx it is as fees in the commitment tx. So from that perspective the channel has to go onchain even though the money is "lost" as fees anyway and it might seem plausible to just keep the channel open to save onchain fees. (I did not check how implementations actually handle this) </p>

<p>Now there seems to be an economic argument (or a potential draining attack) if it was the case that the channel would not drop on chain. I could route thousands of sub dustlimit payments through a node but always through the same channel which I control but never fulfill. In that way I could steel money from you. Though in practice that won't work too well as I could only set up up to 483 such htlcs concurrently and wait for the timeout. If I wanted to do the attack sequentially to repeat it to higher numbers setting up a new htlc would include resolving the old one off chain otherwise you would not sign the new state.</p>

<p>That being said in general there exist quite some nasty attacks with htlcs and fees. </p>

CC BY-SA 4.0
2019-11-17T02:34:35.597Z
But this is ambiguous: an HTLC that doesn't have its own output is not _really_ an HTLC, so do these sections of the spec really apply to them?
fiatjaf
CC BY-SA 4.0
2019-11-17T08:05:59.897Z
Onchain it is no htlc. Without output no contact. But from the perspective of the protocol and off chain as a new state is negotiated and the entire Update process of BOLT 02 is applied it is a hashed timelock contract. We could make an issue in the lightning rfc to a) ask if it is like that and b) to give the hint that the production text should be less ambiguous / easier to interpret at that point. And of course reading code would also help to see how everyone interprets this
Rene Pickhardt
CC BY-SA 4.0
2019-11-16T08:10:28.717Z
2019-11-16T08:10:28.717Z
Rene Pickhardt
<p>When routed Lightning payments are smaller than some amount they don't get their own HTLC output in the commitment transaction. Instead the funds reserved to it are directed to transaction fees.</p>

<p>When there's an actual HTLC it makes sense for the sender to close the channel and claim it back when it's expired, but it makes no sense to do the same when there's not a real HTLC in there. The same applies to the receiver.</p>

<p>But still, will a channel close in these circumstances?</p>

<lightning-network>
Will a channel be automatically closed if there's a expiring HTLC that doesn't have its own output in the commitment transaction?
fiatjaf
# Will a channel be automatically closed if there's a expiring HTLC that doesn't have its own output in the commitment transaction?

(Asked by: username_0 on 2019-11-16)

When routed Lightning payments are smaller than some amount they don't get their own HTLC output in the commitment transaction. Instead the funds reserved to it are directed to transaction fees.

When there's an actual HTLC it makes sense for the sender to close the channel and claim it back when it's expired, but it makes no sense to do the same when there's not a real HTLC in there. The same applies to the receiver.

But still, will a channel close in these circumstances?

**Tags:** lightning-network


---

## 2 answers

### Answer by username_1 on 2019-11-16. Score: 1 | Accepted answer

If it's a mutual close, the HTLC will be resolved prior to closing of the channel. If the close is unilateral, then yes the HTLC which is below the `dust_limit_satoshi` cannot be resolved. When you are adding HTLC below the `dust_limit_satoshi` there is some trust element involved and hence we deduct the HTLC amount from our "balance" as a fee in the commitment transaction.

The bigger question at play is asking yourself why you are closing the channel unilaterally. There may be a number of reasons like peer is unresponsive, peer has fallen behind, or worse peer is trying to cheat. In such cases, protecting your balance in the channel is much more important than a couple of satoshis that might have been added below the dust limit.

Moreover, the fees that you will pay for unilateral close will also be higher than a mutual close. If the commitment transaction had a bunch of HTLCs, the fees from the transaction size will be much higher than the couple of satoshis that you might have added in form of HTLC that you have forwarded. So, when you broadcast the commitment transaction for the unilateral close containing HTLCs below dust limit, you will lose that much amount if you have forwarded the HTLC. Your peer will lose the HTLC amount (below dust) if it was the one that had forwarded the HTLC.


---

### Answer by username_2 on 2019-11-16. Score: 1

I just tried to chase that edge case down in the BOLTs. We find at <https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#cltv_expiry_delta-selection>

> if an HTLC it has fulfilled is in either node's current commitment transaction, AND is past this fulfillment deadline: MUST fail the channel.

While the htlc below the dust limit is not an output in the commitment tx it is as fees in the commitment tx. So from that perspective the channel has to go onchain even though the money is "lost" as fees anyway and it might seem plausible to just keep the channel open to save onchain fees. (I did not check how implementations actually handle this)

Now there seems to be an economic argument (or a potential draining attack) if it was the case that the channel would not drop on chain. I could route thousands of sub dustlimit payments through a node but always through the same channel which I control but never fulfill. In that way I could steel money from you. Though in practice that won't work too well as I could only set up up to 483 such htlcs concurrently and wait for the timeout. If I wanted to do the attack sequentially to repeat it to higher numbers setting up a new htlc would include resolving the old one off chain otherwise you would not sign the new state.

That being said in general there exist quite some nasty attacks with htlcs and fees.

> **Comments:**
> **username_0**: But this is ambiguous: an HTLC that doesn't have its own output is not _really_ an HTLC, so do these sections of the spec really apply to them?  
> **username_2**: Onchain it is no htlc. Without output no contact. But from the perspective of the protocol and off chain as a new state is negotiated and the entire Update process of BOLT 02 is applied it is a hashed timelock contract. We could make an issue in the lightning rfc to a) ask if it is like that and b) to give the hint that the production text should be less ambiguous / easier to interpret at that point. And of course reading code would also help to see how everyone interprets this  

---

