How can I create HTLCs below dust_limit_satoshi in Lightning Network?

Question

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?

Answer 1

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