Good morning Antoine,
As well, I considered doing state machine shenanigans for this (do not sign for
removal of HTLC in your outgoing channel until you have irrevocable removal of
HTLC in your incoming channel) but this does not work since if you already have
a miner willing to cooperate with
Hi ZmnSCPxj,
As of today, you can setup a `htlc_minimum_msat` higher than remote's
`dust_limit_satoshis`, but you don't necessarily know it before announcing
your channel parameters if you're initiator.
In practice, assuming you can do so, with fees going higher and HTLC
outputs being encumbered,
Good morning Antoine,
> Mitigating may come by negotiating a new `max_dust_htlc_value_in_flight_msat`
> enforced by HTLC recipient, therefore expressing its maximum trust tolerance
> with regards to dust. Bearing a cost on a HTLC holder will also render the
> attack more expensive, even if for
Lightning protocol supports a floating dust output selection at channel
creation, where each party declares a dust parameter applying to its local
transactions. The current spec doesn't enforce or recommend any bound on
this value, beyond the requirement of being lower that
`channel_reserve_satoshi
