From antoine.riard at gmail.com Tue May 19 22:03:02 2020 From: antoine.riard at gmail.com (Antoine Riard) Date: Tue, 19 May 2020 18:03:02 -0400 Subject: [Lightning-dev] Miners Dust Inflation attacks on Lightning Network In-Reply-To: <4tUTI-rUr2n5BpMr_d7D_FN_av5TNHCex10PgfwJUxMPrkkowY8IpWawB5U1t9HP5rVnE6JL8nv5i8Y9aRIQTUzU1Z47Bho_aeNqXr-P84I=@protonmail.com> References: <4tUTI-rUr2n5BpMr_d7D_FN_av5TNHCex10PgfwJUxMPrkkowY8IpWawB5U1t9HP5rVnE6JL8nv5i8Y9aRIQTUzU1Z47Bho_aeNqXr-P84I=@protonmail.com> Message-ID: 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, their cost-to-spend will increase so forbidding dust HTLC will outlaw low-value payments, which them are a constant. > Adding this to the spec does have the advantage that an honest forwarder can hold an HTLC for a while once it notices that the next hop has a bunch of dusty HTLCs in-flight that are beyond the negotiated `max_dust_htlc_value_in_flight_msat`, which might help reliability of micropayments slightly, but there is still the reduction of reliability. I agree you can already fail HTLC as a local forwarding policy, which is not great for reliability. So you may have either a negotiated `max_dust_htlc_value_in_flight_msat` or refuse an `open_channel`/`accept_channel` by receiver considering remote's `dust_limit_satoshi` too high. I do think that's a pretty low-risk scenario but that would be better if implementations somehow bound in-flight dust to lower attack incentive. Antoine Le lun. 18 mai 2020 ? 20:52, ZmnSCPxj a ?crit : > 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 > counter-measure efficiency you likely need a different order of magnitude > that spam-protection. > > Even without a spec change, such a setting may be enforced by a forwarding > node by the simple act of refusing to forward an HTLC once a certain level > of incoming dust HTLCs are currently in-flight. > That is, the forwarding node can simply accept the incoming new dusty > HTLC, but instead of forwarding, claim a `temporary_channel_failure` on the > next channel. > The attack requires that the forwarding node actually forward the HTLC, > after all. > > This will of course lead to reduced reliability on micropayments. > > Adding this to the spec does have the advantage that an honest forwarder > can hold an HTLC for a while once it notices that the next hop has a bunch > of dusty HTLCs in-flight that are beyond the negotiated > `max_dust_htlc_value_in_flight_msat`, which might help reliability of > micropayments slightly, but there is still the reduction of reliability. > Not to mention that the easiest code change to respect such a limit would > be simply to fail forwarding anyway. > > Regards, > ZmnSCPxj > -------------- next part -------------- An HTML attachment was scrubbed... URL: