Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

[Antoine Riard]

I've been informed by Mitre, the correct CVE assignment:
* c-lightning : CVE-2021-41592
* lnd: CVE-2021-41593

Not the assignement disclosed in the initial mail.

Le lun. 4 oct. 2021 à 11:09, Antoine Riard  a
écrit :

> Hi,
>
> I'm writing a report to disclose specification-level vulnerabilities
> affecting the Lightning implementations.
>
> The vulnerabilities are expected to be patched in:
> * Eclair: v0.6.2+ (CVE-2021-41591)
> * LND: v0.13.3+ (CVE-2021-41592)
> * LDK: v0.0.102 (not released as production software yet)
>
> The vulnerabilities are also affecting c-lightning (CVE-2021-41593).
>
> Those vulnerabilities can be exploited in a wide range of attacks, going
> from fee blackmailing of node operators, burning liquidity of your
> competing LSPs or even stealing your counterparty channel balance if you
> avail mining capabilities. Exercise of the vulnerability revealed that a
> majority of the balance funds can be at loss.
>
> Credit to Eugene Siegel (Crypt-iQ) for reporting the trimmed-to-dust
> exploitation and multiple insights about attacks.
>
> Thanks to Bastien Teinturier and Matt Corallo for numerous contributions
> about mitigations development.
>
> # Problem
>
> The current BOLT specification only requires Alice's `dust_limit_satoshis`
> (applied on Alice's commitment) to be under Alice's
> `channel_reserve_satoshis` (applied on Bob). As those 2 parameters are
> selectable by Alice, she can inflate the dust limit until reaching the
> implementation-defined max value (e.g LND: 20% of chan capacity, LDK: 100%
> of chan capacity).
>
> Any in-flight incoming HTLC under Alice's dust limit will be converted as
> miner fees on Alice's commitment. This HTLC is deducted from Bob's balance
> and as such they're still owned by Bob, until resolution (i.e a RAA
> removing the HTLC from Alice's commitment). This limitation only applies
> per-HTLC. No implementation enforces a limit on the sum of in-flight HTLCs
> burned as fees. Therefore, Alice is free to inflict a substantial loss to
> Bob funds by publishing her commitment on-chain.
>
> In-flight outgoing HTLC are also committed as fees on Bob's commitment if
> they're under Bob's threshold. Alice can also exploit from this angle by
> circular routing HTLCs until reaching Bob's
> `max_htlc_value_in_flight_msat`. Alice withholds HTLCs resolution until Bob
> goes on-chain to timeout an offered HTLC or claim an accepted HTLC.
>
> Dust HTLC processing can be also exploited at `update_fee` reception.
>
> As the BOLT3's fees computation encompasses the negotiated feerate from
> `update_fee` for the 2nd-stage HTLC fees to decide if the HTLC must be
> trimmed, the amount of balance at risk is a function of current mempool
> feerates.
>
> The maximum of funds at risk on a counterparty commitment is:
>
> counterparty's `max_accepted_htlcs` * (`htlc_success_tx_kw` * opener's
> `feerate_per_kw` + counterparty's `dust_limit_satoshis`) + holder's
> `max_accepted_htlcs` * (`htlc_timeout_tx_kw` * opener's `feerate_per_kw` +
> counterparty's `dust_limit_satoshis`)
>
> If the opener is also the attacker, the negotiated feerate can be
> manipulated beyond the "honest" mempool feerates only upper bounded
> implementation-defined value (before fixes, LDK: 2 * high-feerate of our
> fee-estimator). If the opener is the victim, the negotiated feerate is
> still a safety concern in case of spontaneous mempool spikes.
>
> Note, `anchors_zero_htlc_fee` channels are not affected by the feerate
> inflation as the trimmed-to-dust fee computation mechanism for 2nd-stage
> HTLC is removed. They're still at risk of the sum of the HTLCs under the
> dust limit being maliciously burned.
>
> # Solution
>
> A first mitigation is to verify the counterparty's announced
> `dust_limit_satoshis` at channel opening (`open_channel`/`accept_channel`)
> reception and reject if it's estimated too large (see #894)
>
> For LDK, we choose the value of 660 satoshis as it's beyond the highest
> dust threshold enforced by Bitcoin Core (p2pkh: 546) with a margin of
> safety. Propagation of Lightning time-sensitive transactions shouldn't be
> affected.
>
> A second mitigation is to define a new configurable limit
> `max_dust_htlc_exposure` and apply this one at incoming and outgoing of
> HTLC.
>
> For LDK, we choose the value of 5 000 000 milli-satoshis as we gauged this
> value as a substantial loss for our class of users. Setting this too low
> may prevent the sending or receipt of low-value HTLCs on high-traffic
> nodes. A node operator should fine-tune this value in function of what
> qualifies as an acceptable loss.
>
> We would like to ensure that the node isn't suddenly exposed to
> significantly more trimmed balance if the feerate increases when we have
> several HTLCs pending which are near the dust limit.
>
> To achieve this goal, we introduce a new `dust_buffer_feerate` defined as
> the maximum of either 2530 sats per kWU or 125% of the current
> `feerate_per_kw` (implementation-defined 

Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

[Antoine Riard]

> * C-lightning v0.10.2 (CVE-2021-41593)

Thanks I was unsure about the exact version number. I'll update the CVE
quickly.

Le lun. 4 oct. 2021 à 14:16, lisa neigut  a écrit :

> FYI the next version of c-lightning will contain the proposed
> `max_dust_htlc_exposure_msat` as outlined in #919
> ; the
> given expected vulnerabilities patch table should have reflected this.
>
> > The vulnerabilities are expected to be patched in:
> > * Eclair: v0.6.2+ (CVE-2021-41591)
> > * LND: v0.13.3+ (CVE-2021-41592)
> > * LDK: v0.0.102 (not released as production software yet)
>
> * C-lightning v0.10.2 (CVE-2021-41593)
>
>
> Lisa
>
> On Mon, Oct 4, 2021 at 10:09 AM Antoine Riard 
> wrote:
>
>> Hi,
>>
>> I'm writing a report to disclose specification-level vulnerabilities
>> affecting the Lightning implementations.
>>
>> The vulnerabilities are expected to be patched in:
>> * Eclair: v0.6.2+ (CVE-2021-41591)
>> * LND: v0.13.3+ (CVE-2021-41592)
>> * LDK: v0.0.102 (not released as production software yet)
>>
>> The vulnerabilities are also affecting c-lightning (CVE-2021-41593).
>>
>> Those vulnerabilities can be exploited in a wide range of attacks, going
>> from fee blackmailing of node operators, burning liquidity of your
>> competing LSPs or even stealing your counterparty channel balance if you
>> avail mining capabilities. Exercise of the vulnerability revealed that a
>> majority of the balance funds can be at loss.
>>
>> Credit to Eugene Siegel (Crypt-iQ) for reporting the trimmed-to-dust
>> exploitation and multiple insights about attacks.
>>
>> Thanks to Bastien Teinturier and Matt Corallo for numerous contributions
>> about mitigations development.
>>
>> # Problem
>>
>> The current BOLT specification only requires Alice's
>> `dust_limit_satoshis` (applied on Alice's commitment) to be under Alice's
>> `channel_reserve_satoshis` (applied on Bob). As those 2 parameters are
>> selectable by Alice, she can inflate the dust limit until reaching the
>> implementation-defined max value (e.g LND: 20% of chan capacity, LDK: 100%
>> of chan capacity).
>>
>> Any in-flight incoming HTLC under Alice's dust limit will be converted as
>> miner fees on Alice's commitment. This HTLC is deducted from Bob's balance
>> and as such they're still owned by Bob, until resolution (i.e a RAA
>> removing the HTLC from Alice's commitment). This limitation only applies
>> per-HTLC. No implementation enforces a limit on the sum of in-flight HTLCs
>> burned as fees. Therefore, Alice is free to inflict a substantial loss to
>> Bob funds by publishing her commitment on-chain.
>>
>> In-flight outgoing HTLC are also committed as fees on Bob's commitment if
>> they're under Bob's threshold. Alice can also exploit from this angle by
>> circular routing HTLCs until reaching Bob's
>> `max_htlc_value_in_flight_msat`. Alice withholds HTLCs resolution until Bob
>> goes on-chain to timeout an offered HTLC or claim an accepted HTLC.
>>
>> Dust HTLC processing can be also exploited at `update_fee` reception.
>>
>> As the BOLT3's fees computation encompasses the negotiated feerate from
>> `update_fee` for the 2nd-stage HTLC fees to decide if the HTLC must be
>> trimmed, the amount of balance at risk is a function of current mempool
>> feerates.
>>
>> The maximum of funds at risk on a counterparty commitment is:
>>
>> counterparty's `max_accepted_htlcs` * (`htlc_success_tx_kw` * opener's
>> `feerate_per_kw` + counterparty's `dust_limit_satoshis`) + holder's
>> `max_accepted_htlcs` * (`htlc_timeout_tx_kw` * opener's `feerate_per_kw` +
>> counterparty's `dust_limit_satoshis`)
>>
>> If the opener is also the attacker, the negotiated feerate can be
>> manipulated beyond the "honest" mempool feerates only upper bounded
>> implementation-defined value (before fixes, LDK: 2 * high-feerate of our
>> fee-estimator). If the opener is the victim, the negotiated feerate is
>> still a safety concern in case of spontaneous mempool spikes.
>>
>> Note, `anchors_zero_htlc_fee` channels are not affected by the feerate
>> inflation as the trimmed-to-dust fee computation mechanism for 2nd-stage
>> HTLC is removed. They're still at risk of the sum of the HTLCs under the
>> dust limit being maliciously burned.
>>
>> # Solution
>>
>> A first mitigation is to verify the counterparty's announced
>> `dust_limit_satoshis` at channel opening (`open_channel`/`accept_channel`)
>> reception and reject if it's estimated too large (see #894)
>>
>> For LDK, we choose the value of 660 satoshis as it's beyond the highest
>> dust threshold enforced by Bitcoin Core (p2pkh: 546) with a margin of
>> safety. Propagation of Lightning time-sensitive transactions shouldn't be
>> affected.
>>
>> A second mitigation is to define a new configurable limit
>> `max_dust_htlc_exposure` and apply this one at incoming and outgoing of
>> HTLC.
>>
>> For LDK, we choose the value of 5 000 000 milli-satoshis as we gauged
>> this value as a substantial 

Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

[Antoine Riard]

> In other words, simply not secured.

How do you define Bitcoin base-layer security ? How strong are the
assumptions we're relying on the base-layer ?
Not easy answers :/

> L2s shouldn't build on flawed assumptions.

Waiting for your proposal to scale Bitcoin payments relying on pure
consensus assumptions :)

> No thanks. Not sure that would even help (since policies can always be
set to
a higher dust limit than any consensus rule)

Sure. Policies can always be more restrictive. One of them could be to not
relay transactions at all. If widely-deployed, such policy would make the
network quite unusable

More seriously, I think when we consider this policy discussion, we should
have more in mind the consequences of adopting a given policy or another
one.
As long as they're economically-compatible, they should be followed by an
economically rational node operator.
I think we're already making that kind of social or economic assumption on
the user behavior w.r.t to full-node design. Blocks and transactions are
relayed for "free" today, not satoshis are received in exchange.


Le lun. 4 oct. 2021 à 12:28, Luke Dashjr  a écrit :

> On Monday 04 October 2021 16:14:20 Antoine Riard wrote:
> > > The "dust limit" is arbitrarily decided by each node, and cannot be
> > > relied upon for security at all. Expecting it to be a given default
> value
> > > is in itself a security vulnerability
> >
> > Reality is that an increasing number of funds are secured by assumptions
> > around mempool behavior.
>
> In other words, simply not secured.
>
> > And sadly that's going to increase with Lightning growth and deployment
> of
> > other L2s.
>
> L2s shouldn't build on flawed assumptions.
>
> > Maybe we could dry-up some policy rules in consensus like the dust limit
> > one :)
>
> No thanks. Not sure that would even help (since policies can always be set
> to
> a higher dust limit than any consensus rule)
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

[lisa neigut]

FYI the next version of c-lightning will contain the proposed
`max_dust_htlc_exposure_msat` as outlined in #919
; the
given expected vulnerabilities patch table should have reflected this.

> The vulnerabilities are expected to be patched in:
> * Eclair: v0.6.2+ (CVE-2021-41591)
> * LND: v0.13.3+ (CVE-2021-41592)
> * LDK: v0.0.102 (not released as production software yet)

* C-lightning v0.10.2 (CVE-2021-41593)


Lisa

On Mon, Oct 4, 2021 at 10:09 AM Antoine Riard 
wrote:

> Hi,
>
> I'm writing a report to disclose specification-level vulnerabilities
> affecting the Lightning implementations.
>
> The vulnerabilities are expected to be patched in:
> * Eclair: v0.6.2+ (CVE-2021-41591)
> * LND: v0.13.3+ (CVE-2021-41592)
> * LDK: v0.0.102 (not released as production software yet)
>
> The vulnerabilities are also affecting c-lightning (CVE-2021-41593).
>
> Those vulnerabilities can be exploited in a wide range of attacks, going
> from fee blackmailing of node operators, burning liquidity of your
> competing LSPs or even stealing your counterparty channel balance if you
> avail mining capabilities. Exercise of the vulnerability revealed that a
> majority of the balance funds can be at loss.
>
> Credit to Eugene Siegel (Crypt-iQ) for reporting the trimmed-to-dust
> exploitation and multiple insights about attacks.
>
> Thanks to Bastien Teinturier and Matt Corallo for numerous contributions
> about mitigations development.
>
> # Problem
>
> The current BOLT specification only requires Alice's `dust_limit_satoshis`
> (applied on Alice's commitment) to be under Alice's
> `channel_reserve_satoshis` (applied on Bob). As those 2 parameters are
> selectable by Alice, she can inflate the dust limit until reaching the
> implementation-defined max value (e.g LND: 20% of chan capacity, LDK: 100%
> of chan capacity).
>
> Any in-flight incoming HTLC under Alice's dust limit will be converted as
> miner fees on Alice's commitment. This HTLC is deducted from Bob's balance
> and as such they're still owned by Bob, until resolution (i.e a RAA
> removing the HTLC from Alice's commitment). This limitation only applies
> per-HTLC. No implementation enforces a limit on the sum of in-flight HTLCs
> burned as fees. Therefore, Alice is free to inflict a substantial loss to
> Bob funds by publishing her commitment on-chain.
>
> In-flight outgoing HTLC are also committed as fees on Bob's commitment if
> they're under Bob's threshold. Alice can also exploit from this angle by
> circular routing HTLCs until reaching Bob's
> `max_htlc_value_in_flight_msat`. Alice withholds HTLCs resolution until Bob
> goes on-chain to timeout an offered HTLC or claim an accepted HTLC.
>
> Dust HTLC processing can be also exploited at `update_fee` reception.
>
> As the BOLT3's fees computation encompasses the negotiated feerate from
> `update_fee` for the 2nd-stage HTLC fees to decide if the HTLC must be
> trimmed, the amount of balance at risk is a function of current mempool
> feerates.
>
> The maximum of funds at risk on a counterparty commitment is:
>
> counterparty's `max_accepted_htlcs` * (`htlc_success_tx_kw` * opener's
> `feerate_per_kw` + counterparty's `dust_limit_satoshis`) + holder's
> `max_accepted_htlcs` * (`htlc_timeout_tx_kw` * opener's `feerate_per_kw` +
> counterparty's `dust_limit_satoshis`)
>
> If the opener is also the attacker, the negotiated feerate can be
> manipulated beyond the "honest" mempool feerates only upper bounded
> implementation-defined value (before fixes, LDK: 2 * high-feerate of our
> fee-estimator). If the opener is the victim, the negotiated feerate is
> still a safety concern in case of spontaneous mempool spikes.
>
> Note, `anchors_zero_htlc_fee` channels are not affected by the feerate
> inflation as the trimmed-to-dust fee computation mechanism for 2nd-stage
> HTLC is removed. They're still at risk of the sum of the HTLCs under the
> dust limit being maliciously burned.
>
> # Solution
>
> A first mitigation is to verify the counterparty's announced
> `dust_limit_satoshis` at channel opening (`open_channel`/`accept_channel`)
> reception and reject if it's estimated too large (see #894)
>
> For LDK, we choose the value of 660 satoshis as it's beyond the highest
> dust threshold enforced by Bitcoin Core (p2pkh: 546) with a margin of
> safety. Propagation of Lightning time-sensitive transactions shouldn't be
> affected.
>
> A second mitigation is to define a new configurable limit
> `max_dust_htlc_exposure` and apply this one at incoming and outgoing of
> HTLC.
>
> For LDK, we choose the value of 5 000 000 milli-satoshis as we gauged this
> value as a substantial loss for our class of users. Setting this too low
> may prevent the sending or receipt of low-value HTLCs on high-traffic
> nodes. A node operator should fine-tune this value in function of what
> qualifies as an acceptable loss.
>
> We would like to ensure that the node isn't suddenly exposed 

Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

[Luke Dashjr]

On Monday 04 October 2021 16:14:20 Antoine Riard wrote:
> > The "dust limit" is arbitrarily decided by each node, and cannot be
> > relied upon for security at all. Expecting it to be a given default value
> > is in itself a security vulnerability
>
> Reality is that an increasing number of funds are secured by assumptions
> around mempool behavior.

In other words, simply not secured.

> And sadly that's going to increase with Lightning growth and deployment of
> other L2s.

L2s shouldn't build on flawed assumptions.

> Maybe we could dry-up some policy rules in consensus like the dust limit
> one :)

No thanks. Not sure that would even help (since policies can always be set to 
a higher dust limit than any consensus rule)
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

[Antoine Riard]

> The "dust limit" is arbitrarily decided by each node, and cannot be
relied
upon for security at all. Expecting it to be a given default value is in
itself a security vulnerability

Reality is that an increasing number of funds are secured by assumptions
around mempool behavior.
And sadly that's going to increase with Lightning growth and deployment of
other L2s.

Maybe we could dry-up some policy rules in consensus like the dust limit
one :)


Le lun. 4 oct. 2021 à 11:57, Luke Dashjr  a écrit :

> On Monday 04 October 2021 15:09:28 Antoine Riard wrote:
> > Still during August 2021, the Bitcoin Core dust limit was actively
> > discussed on the mailing list. Changes of this dust limit would have
> > affected the ongoing development of the mitigations.
>
> The "dust limit" is arbitrarily decided by each node, and cannot be relied
> upon for security at all. Expecting it to be a given default value is in
> itself a security vulnerability.
>
>
> P.S. It'd be nice if someone familiar with these could fill in
> https://en.bitcoin.it/wiki/CVEs
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

[Luke Dashjr]

On Monday 04 October 2021 15:09:28 Antoine Riard wrote:
> Still during August 2021, the Bitcoin Core dust limit was actively
> discussed on the mailing list. Changes of this dust limit would have
> affected the ongoing development of the mitigations.

The "dust limit" is arbitrarily decided by each node, and cannot be relied 
upon for security at all. Expecting it to be a given default value is in 
itself a security vulnerability.


P.S. It'd be nice if someone familiar with these could fill in 
https://en.bitcoin.it/wiki/CVEs
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

[Antoine Riard]

Hi,

I'm writing a report to disclose specification-level vulnerabilities
affecting the Lightning implementations.

The vulnerabilities are expected to be patched in:
* Eclair: v0.6.2+ (CVE-2021-41591)
* LND: v0.13.3+ (CVE-2021-41592)
* LDK: v0.0.102 (not released as production software yet)

The vulnerabilities are also affecting c-lightning (CVE-2021-41593).

Those vulnerabilities can be exploited in a wide range of attacks, going
from fee blackmailing of node operators, burning liquidity of your
competing LSPs or even stealing your counterparty channel balance if you
avail mining capabilities. Exercise of the vulnerability revealed that a
majority of the balance funds can be at loss.

Credit to Eugene Siegel (Crypt-iQ) for reporting the trimmed-to-dust
exploitation and multiple insights about attacks.

Thanks to Bastien Teinturier and Matt Corallo for numerous contributions
about mitigations development.

# Problem

The current BOLT specification only requires Alice's `dust_limit_satoshis`
(applied on Alice's commitment) to be under Alice's
`channel_reserve_satoshis` (applied on Bob). As those 2 parameters are
selectable by Alice, she can inflate the dust limit until reaching the
implementation-defined max value (e.g LND: 20% of chan capacity, LDK: 100%
of chan capacity).

Any in-flight incoming HTLC under Alice's dust limit will be converted as
miner fees on Alice's commitment. This HTLC is deducted from Bob's balance
and as such they're still owned by Bob, until resolution (i.e a RAA
removing the HTLC from Alice's commitment). This limitation only applies
per-HTLC. No implementation enforces a limit on the sum of in-flight HTLCs
burned as fees. Therefore, Alice is free to inflict a substantial loss to
Bob funds by publishing her commitment on-chain.

In-flight outgoing HTLC are also committed as fees on Bob's commitment if
they're under Bob's threshold. Alice can also exploit from this angle by
circular routing HTLCs until reaching Bob's
`max_htlc_value_in_flight_msat`. Alice withholds HTLCs resolution until Bob
goes on-chain to timeout an offered HTLC or claim an accepted HTLC.

Dust HTLC processing can be also exploited at `update_fee` reception.

As the BOLT3's fees computation encompasses the negotiated feerate from
`update_fee` for the 2nd-stage HTLC fees to decide if the HTLC must be
trimmed, the amount of balance at risk is a function of current mempool
feerates.

The maximum of funds at risk on a counterparty commitment is:

counterparty's `max_accepted_htlcs` * (`htlc_success_tx_kw` * opener's
`feerate_per_kw` + counterparty's `dust_limit_satoshis`) + holder's
`max_accepted_htlcs` * (`htlc_timeout_tx_kw` * opener's `feerate_per_kw` +
counterparty's `dust_limit_satoshis`)

If the opener is also the attacker, the negotiated feerate can be
manipulated beyond the "honest" mempool feerates only upper bounded
implementation-defined value (before fixes, LDK: 2 * high-feerate of our
fee-estimator). If the opener is the victim, the negotiated feerate is
still a safety concern in case of spontaneous mempool spikes.

Note, `anchors_zero_htlc_fee` channels are not affected by the feerate
inflation as the trimmed-to-dust fee computation mechanism for 2nd-stage
HTLC is removed. They're still at risk of the sum of the HTLCs under the
dust limit being maliciously burned.

# Solution

A first mitigation is to verify the counterparty's announced
`dust_limit_satoshis` at channel opening (`open_channel`/`accept_channel`)
reception and reject if it's estimated too large (see #894)

For LDK, we choose the value of 660 satoshis as it's beyond the highest
dust threshold enforced by Bitcoin Core (p2pkh: 546) with a margin of
safety. Propagation of Lightning time-sensitive transactions shouldn't be
affected.

A second mitigation is to define a new configurable limit
`max_dust_htlc_exposure` and apply this one at incoming and outgoing of
HTLC.

For LDK, we choose the value of 5 000 000 milli-satoshis as we gauged this
value as a substantial loss for our class of users. Setting this too low
may prevent the sending or receipt of low-value HTLCs on high-traffic
nodes. A node operator should fine-tune this value in function of what
qualifies as an acceptable loss.

We would like to ensure that the node isn't suddenly exposed to
significantly more trimmed balance if the feerate increases when we have
several HTLCs pending which are near the dust limit.

To achieve this goal, we introduce a new `dust_buffer_feerate` defined as
the maximum of either 2530 sats per kWU or 125% of the current
`feerate_per_kw` (implementation-defined values).

Then, upon an incoming HTLC, if the HTLC's `amount_msat` is inferior to the
counterparty's `dust_limit_satoshis` plus the HTLC-timeout fee at the
`dust_buffer_feerate`. If the `amount_msat` plus the
`dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure`,
the HTLC should be failed once it's committed.

Upon an outgoing HTLC, if the HTLC's `amount_msat` is inferior to the