> As developers, we have no
control over prevailing feerates, so this is a problem LN needs to deal
with regardless of Bitcoin Core's dust limit.
Right, as of today, we're going to trim-to-dust any commitment output of which the value is inferior to the transaction owner's `dust_limit_satoshis` plus the HTLC-claim (either success/timeout) fee at the agreed on feerate. So the feerate is the most significant variable in defining what's a LN *uneconomical output*.
IMO this approach presents annoying limitations. First, you still need to come with an agreement among channel operators on the mempools feerate. Such agreement might be problematic to find, as on one side you would like to let your counterparty free to pick up a feerate gauged as efficient for the confirmation of their transactions but at the same time not too high to burn to fees your low-values HTLCs that *your* fee-estimator judged as sane to claim.
Secondly, the trim-to-dust evaluation doesn't correctly match the lifetime of the HTLC. A HTLC might be considered as dust at block 100, at which mempools are full. Though its expiration only occurs at block 200, at which mempools are empty and this HTLC is fine to claim again. I think this inaccuracy will even become worse with a wider deployment of long-lived routed packets over LN, such as DLCs or hodl invoices.
All this to say, if for those reasons LN devs remove feerate negotiation from the trim-to-dust definition to a static feerate, it would likely put a higher pressure on the full-nodes operators, as the number of uneconomical outputs might increase.
(From a LN viewpoint, I would say we're trying to solve a price discovery issue, namely the cost to write on the UTXO set, in a distributed system, where any deviation from the "honest" price means you trust more your LN counterparty)
> They could also use trustless probabalistic payments, which have been
discussed in the context of LN for handling the problem of payments too
small to be represented onchain since early 2016:
https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098Thanks to bringing to the surface probabilistic payments, yes that's a worthy alternative approach for low-value payments to keep in mind.