"HTLCs don't work for micropayments"? I read this tweet by Tadge Dryja recently. What exactly did he mean? Is this an issue? If so, is this issue fixable?
It takes about 200 vbytes to spend from a Lightning Network (LN) Hashed
Time-Locked Contract (HTLC) output used for routing a payment.  At the default
minimum feerate of 10 nBTC/vbyte, that makes it uneconomical to attempt to
claim a routed micropayment below about 2,000 nBTC ($0.008 USD at $4,000
USD/BTC).  As fees rise, larger and larger micropayments become uneconomical to
claim.

Worse, the default Bitcoin Core mempool policy attempts to prevent UTXO-set
bloat attacks by refusing to relay or mine any transaction containing an output
that would be uneconomical to spend at a feerate of 30 nBTC/vbyte.  This is
called the dust limit.  To obey this limit, LN nodes must not include HTLCs
for very small micropayments in LN offchain transactions---otherwise those
transactions couldn't be confirmed onchain if necessary and other value in the
channel could be stolen by a counterparty.

Currently, when LN nodes are asked to route payments below the dust limit, they
trim those HTLCs by increasing
the potential transaction fee of their channel by the amount of the
micropayment rather than adding an HTLC.  This fee only actually pays miners if
the channel is closed in a state that includes this fee---by mutual agreement
between channel counterparties, the fee can be removed in a later state.  This
creates three possible outcomes:


The fee is removed in a later state because both peers agree that the
micropayment completed successfully, so the amount is trasfered into a
normal-size output that's not subject to the dust limit.
The fee is removed in a later state because both peers agree that the
micropayment failed (either it was rejected or it timed out).  The earlier
state where the funds were held in a larger output is restored.
The two peers get into a disagreement about the payment and close the
channel.  In this case, the funds are actually transfered to miners and are
lost to whichever channel party was technically correct about the final
payment state.


Peter Rizun has
argued that, combined with rising Bitcoin transaction fees, this can lead to "the problem where even $50 payments are not 'trustless.' In the case where $50 is below the dust threshold [...], then HTLCs cannot be used to protect the $50 payment. Customers can lose $50 payments through no fault of their own."

It seems like he might be correct, although there are a few evasions we could
make about the current network behavior:


The amounts involved are currently tiny (about $0.02 at $4,000 USD/BTC).
Node operators who want to eliminate their risk can simply refuse to route
micropayments below the dust limit.
Those willing to accept limited risk can limit their maximum exposure (e.g.
only routing up to 10 payments below $0.02 for a maximum risk of $0.20).  


However, what we really want is a fundamental solution to this risk---a way to
make even micropayments trustless.  Happily, the person quoted in the
question---Thaddeus Dryja (one of the original LN architects)---previously
described
how this might be accomplished.

Removing trust from inexpressible values

Above we described micropayments below the dust limit, which is a relay and
mining policy (meaning it can be changed without needing global consensus).
However, LN also allows micropayments down to 10 pBTC, which is 1/1,000th the
consensus-enforced 10 nBTC maximum precision of onchain Bitcoin.

When a channel contains some value that can't be represented onchain, the
remaining value is tracked in a database and LN commitments are made using
rounding.  For example, if 6 nBTC are paid from Alice's side of a channel to
Bob's side of a channel, she might actually send him 10 nBTC in an offchain transaction and the
extra 4 nBTC are tracked in a database to be credited towards subsequent payments.  If the channel is closed at this
point, Alice accepts that she's going to lose those 4 nBTC ($0.00002 USD at
$4,000 USD/BTC).

Given the tiny amounts involved, that seems like a perfectly satisfactory
solution---Bob's unlikely to pay an onchain transaction fee of 4,000 nBTC just
to steal 4 nBTC from Alice.  But, in early LN presentations, Dryja proposed an
alternative technique based on something occasionally discussed among Bitcoin
protocol developers: probabilistic payments.

Probabilistic payments are payments that only succeed a specified percentage of
the time.  For example, Alice wants to pay Bob 1 nBTC, but that's smaller than
allowed by Bitcoin.  Instead she offers him a probabilistic payment of 10 nBTC
(the smallest Bitcoin does allow) with 1-in-10 odds.  Nine times out of ten,
Bob gets nothing; one time in ten, he gets 10 nBTC.  If this is done with a provably fair protocol and the distribution amounts are symmetric to the odds (i.e. there's no house edge), then it's reasonable to believe that receiving 10 nBTC 1/10th of the time is equivalent to receiving 1 nBTC each time.

The exact mechanism described by Dryja is complicated and I don't know how well
it's been reviewed for security.  A large problem faced by all ideas for
probabilistic payments on Bitcoin is that they're hard or impossible to
implement in Bitcoin's very limited Script language.  Sidechains based on
ElementsProject.org, such as Blockstream Liquid, have re-enabled some disabled
math opcodes from Bitcoin plus added an
OP_DETERMINISTICRANDOM opcode
that make probabilistic payments much easier to implement there (although I'm
unaware of any specific work on a definite protocol).  Perhaps someday, these
opcodes or other similar features will become available on Bitcoin if there is
community demand for them.

Probabilistic payments to circumvent the dust limit

In the previous section, we saw probabilistic payments used to trustlessly get
around the minimum consensus precision of 10 nBTC.  We can use the same
mechanism to get around the dust limit trustlessly.  If it's uneconomical to
spend an HTLC output worth less than 10,000 nBTC, then we simply require
probabilistic payments for any amount below that.

For example, Alice wants to route a 1,000 nBTC payment through Bob.  Bob
requires her to create an HTLC paying him 10,000 nBTC with a 1-in-10 chance of
success.  Then the LN is processed.  If both Alice and Bob agree that it failed, they throw away the
HTLC.  If they both agree it succeeded, Alice simply adds 1,000 nBTC to a larger
output of Bob's, circumventing the dust limit.  If they disagree and the
transaction needs to go onchain, the probabilistic payment is run and, nine
times out of ten, Bob receives nothing (Alice gets her 10,000 nBTC back).  One
time out of ten, Bob receives 10,000 nBTC.  This can be made completely trustless, provably fair, and doesn't require any third parties.

As mentioned above, probabilistic payments are currently a lot of work to
implement on Bitcoin and effective use of them may rely on soft forks that are
just ideas now.  Moreover, while transaction fees are low and Bitcoin valuations
still make dust-size outputs worth just pennies, there's no real need to work
on complex solutions to the problem of people maybe losing a few cents---people who don't want that risk can simply disable routing payments below about $0.02.  But if
this becomes a real problem, it's a problem I think we can reasonably expect to
solve in a completely trustless way.

Addendum: an easier, less clever way to circumvent the dust limit

Several hours after posting the description above, it occurred to me that
there's an easier way to create trustless payments below the dust limit that
doesn't depend on untested probabilistic payments.  If Alice wants to route a
1,000 nBTC payment through Bob but the minimum economical onchain HTLC is
10,000 nBTC, she and Bob simply create two offchain outputs at the same time:
one where Alice pays Bob 11,000 nBTC and one where Bob pays Alice 10,000 nBTC.
Both HTLCs use the same hashlock and timelock, so they can both succeed or timeout at the
same time.  The net effect is a 1,000 nBTC payment to Alice if the offchain
payment needs to be settled onchain, plus the regular ability for them to agree on the outcome and update their main balances cooperatively.

Downsides include that this requires that Alice and Bob keep
more balance in their side of a channel than they otherwise would in order to
handle micropayments and that it costs them more fee overall.  This additional burden can be compensated by them
charging a higher fee for routing payments below the economical onchain rate.
This method also solves the problem in a completely trustless way and it's
something that shouldn't require significant research to implement, although
it's still perhaps a premature optimization while the current risk is measured
in pennies.

(Probabilistic payments are still the only way I know to deal with payments
below the minimum onchain precision of 10 nBTC, but that's not the question here.)