<p>The dust limit is an externality to lightning wich the protocol has to respect. In fact if a commitment transaction would encode an htlc below the dustlimit you could not force close the channel as the Bitcoin network would not accept that particular transaction.</p>

<p>When it comes to htlcs below the dustlevel we work with a little trust in the payment channel. This means that offering an htlc means that we remove some bslance from our side of the channel. Instead of making it an htlc output we just add it to the fees of the commitment transaction. Technically our channel partner could harm us by force closing now and our htlc amount would be lost forever if we don't find the preimage. Only upon delivery of the preimage a new commitment tx is negotiated in which the fee is reduced by the htlc amount and added to your channel partners balance. </p>

<p>That being said. For fee calculations of small payments we even allow subsatoshi amounts which again are not enforceable and will be added to the fees by rounding down the actual balance in the commitment tx. Any routing nodes could implement (actually just configure) a rule like the one you suggested. This would enforce the effect that the channel can be operated fully trustless.</p>

<p>I can't tell you why this is not encoded to the protocol. I think because people wanted to allow micro transactions</p>

CC BY-SA 4.0
2019-05-15T11:19:25.593Z
2019-05-15T11:19:25.593Z
Rene Pickhardt
<p>BOLT#2 documentation for <code>open_channel</code> message has two points (<code>dust_limit_satoshi</code> and <code>htlc_min_msat</code>) in the <code>data</code> message that I found confusing. Below is the statement related to <code>dust_limit_satoshi</code>:</p>

<blockquote>
  <p><code>dust_limit_satoshis</code> is the threshold below which outputs should not be generated for this node's commitment or HTLC transactions (i.e. HTLCs below this amount plus HTLC transaction fees are not enforceable on-chain)</p>
</blockquote>

<p>and for <code>htlc_minimum_msat</code></p>

<blockquote>
  <p><code>htlc_minimum_msat</code> indicates the smallest value HTLC this node will accept.</p>
</blockquote>

<p>My question is how will I be able to accept a htlc with value that is in sub-satoshi, if my <code>dust_limit_satoshi</code> is in Satoshis? As per my understanding and the first statement in quotes, my node will not accept HTLC transactions that are below the <code>dust_limit</code>. If that is the case why not enforce that <code>htlc_minimum_msat</code> > <code>dust_limit_satoshi</code>?</p>

<lightning-network><hash-time-locked-contract>
How can I create HTLCs below dust_limit_satoshi in Lightning Network?
Ugam Kamat
# How can I create HTLCs below dust_limit_satoshi in Lightning Network?

(Asked by: username_0 on 2019-05-15)

BOLT#2 documentation for `open_channel` message has two points (`dust_limit_satoshi` and `htlc_min_msat`) in the `data` message that I found confusing. Below is the statement related to `dust_limit_satoshi`:

> `dust_limit_satoshis` is the threshold below which outputs should not be generated for this node's commitment or HTLC transactions (i.e. HTLCs below this amount plus HTLC transaction fees are not enforceable on-chain)

and for `htlc_minimum_msat`

> `htlc_minimum_msat` indicates the smallest value HTLC this node will accept.

My question is how will I be able to accept a htlc with value that is in sub-satoshi, if my `dust_limit_satoshi` is in Satoshis? As per my understanding and the first statement in quotes, my node will not accept HTLC transactions that are below the `dust_limit`. If that is the case why not enforce that `htlc_minimum_msat` > `dust_limit_satoshi`?

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


---

## 1 answers

### Answer by username_1 on 2019-05-15. Score: 2 | Accepted answer

The dust limit is an externality to lightning wich the protocol has to respect. In fact if a commitment transaction would encode an htlc below the dustlimit you could not force close the channel as the Bitcoin network would not accept that particular transaction.

When it comes to htlcs below the dustlevel we work with a little trust in the payment channel. This means that offering an htlc means that we remove some bslance from our side of the channel. Instead of making it an htlc output we just add it to the fees of the commitment transaction. Technically our channel partner could harm us by force closing now and our htlc amount would be lost forever if we don't find the preimage. Only upon delivery of the preimage a new commitment tx is negotiated in which the fee is reduced by the htlc amount and added to your channel partners balance.

That being said. For fee calculations of small payments we even allow subsatoshi amounts which again are not enforceable and will be added to the fees by rounding down the actual balance in the commitment tx. Any routing nodes could implement (actually just configure) a rule like the one you suggested. This would enforce the effect that the channel can be operated fully trustless.

I can't tell you why this is not encoded to the protocol. I think because people wanted to allow micro transactions


---

