Reject update_fee beyond max_dust_htlc_exposure_msat

Author: ariard

02-peer-protocol.md

@@ -1173,6 +1173,14 @@ The node _responsible_ for paying the Bitcoin fee:
 The node _not responsible_ for paying the Bitcoin fee:
   - MUST NOT send `update_fee`.
 
+A sending node:
+  - if the `dust_balance_on_counterparty_tx` at the new `dust_buffer_feerate` is superior to `max_dust_htlc_exposure_msat`:
+    - MAY NOT send `update_fee`
+    - MAY fail the channel
+  - if the `dust_balance_on_holder_tx` at the new `dust_buffer_feerate` is superior to the `max_dust_htlc_exposure_msat`:
+    - MAY NOT send `update_fee`
+    - MAY fail the channel
+
 A receiving node:
   - if the `update_fee` is too low for timely processing, OR is unreasonably large:
     - SHOULD fail the channel.
@@ -1182,6 +1190,17 @@ A receiving node:
   current commitment transaction:
     - SHOULD fail the channel,
       - but MAY delay this check until the `update_fee` is committed.
+  - if the `dust_balance_on_counterparty_tx` at the new `dust_buffer_feerate` is superior to `max_dust_htlc_exposure_msat`:
+    - MAY fail the channel
+  - if the `dust_balance_on_holder_tx` at the new `dust_buffer_feerate` is superior to the `max_dust_htlc_exposure_msat`:
+    - MAY fail the channel
+
+There is a possibility of triggering a third-party channel closure in case
+of high-fee spikes by forwarding many trimmed HTLCs on this channel and
+waiting for an automatic `update_fee` provoking an unilateral close. For this
+reason, closing the channel in case of `update_fee` overflowing the
+`max_dust_htlc_exposure_msat` is deferred to the node operator, where it should
+be ultimately evaluated in function of the channel trust and robustness.
 
 #### Rationale