Bound exposure to trimmed in-flight HTLCs

Author: ariard

02-peer-protocol.md

@@ -797,6 +797,61 @@ A fulfilling node:
   transaction, AND is past this fulfillment deadline:
     - MUST fail the channel.
 
+### Bounding exposure to trimmed in-flight HTLCs: `max_dust_htlc_exposure_msat`
+
+When a HTLC is present in a channel is below the "trimmed" threshold in [BOLT3 #3](03-transactions.md),
+the HTLC is not claimable on-chain, instead being turned into additional miner
+fees if either party unilaterally closes the channel. Because the threshold is
+per-HTLC, the total exposure to such HTLCs may be substantial if there are many
+dust HTLCs present when the channel is force-closed.
+
+This can be exploited in griefing attacks or even in miner-extractable-value attacks,
+if the malicious entity avails <sup>[mining capabilities](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html)</sup>.
+
+The total exposure is given by the following back-of-the-envelope computation:
+
+	counterparty's `max_accepted_htlcs` * (`HTLC-success-kiloweight` * opener's `feerate_per_kw` + counterparty's `dust_limit_satoshis`)
+		+ holder's `max_accepted_htlcs` * (`HTLC-timeout-kiloweight` * opener's `feerate_per_kw` + counterparty's `dust_limit_satoshis`)
+
+
+To mitigate this scenario, a `max_dust_htlc_exposure_msat` must be apply at
+HTLC sending, forwarding and receiving.
+
+A node:
+  - upon an incoming HTLC:
+    - if a 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_msat`:
+	- SHOULD fail this HTLC once it's committed
+	- SHOULD NOT reveal a preimage for this HTLC
+    - if a HTLC's `amount_msat` is inferior to the holder's `dust_limit_satoshis` plus the HTLC-success fee at the `dust_buffer_feerate`:
+      - if the `amount_msat` plus the `dust_balance_on_holder_tx` is superior to `max_dust_htlc_exposure_msat`:
+	- SHOULD fail this HTLC once it's committed
+        - SHOULD NOT reveal a preimage for this HTLC
+  - upon an outgoing HTLC:
+    - if a HTLC's `amount_msat` is inferior the counterparty's `dust_limit_satoshis` plus the HTLC-success fee at the `dust_buffer_feerate`:
+      - if the `amount_msat` plus the `dust_balance_on_counterparty_tx` is superior to `max_dust_htlc_exposure_msat`:
+        - SHOULD NOT send this HTLC
+	- SHOULD fail this HTLC if it's forwarded
+    - if a HTLC's `amount_msat` is inferior to the holder's `dust_limit_satoshis` plus the HTLC-timeout fee at the `dust_buffer_feerate`:
+      - if the `amount_msat` plus the `dust_balance_on_holder_tx` is superior to `max_dust_htlc_exposure_msat`:
+        - SHOULD NOT send this HTLC
+	- SHOULD fail this HTLC if it's forwarded
+
+`dust_buffer_feerate` is defined as the maximum of either 2530 sats per kWU or
+125% of the current `feerate_per_kw`. This 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.
+
+`dust_balance_on_holder_tx` as the sum:
+	- incoming HTLCs inferior to the holder's `dust_limit_satoshis` plus the HTLC-timeout fee at the `dust_buffer_feerate`
+	- outgoing HTLCs inferior to the holder's `dust_limit_satoshis` plus the HTLC-success fee at the `dust_buffer_feerate`
+	- waiting-a-counterparty-RAA-to-be-removed outgoing HTLCs inferior to the holder's `dust_limit_satoshis` plus the HTLC-timeout fee at the `dust_buffer_feerate`
+
+`dust_balance_on_counterparty_tx` as the sum:
+	- incoming HTLCs inferior to the counterparty's `dust_limit_satoshis` plus the HTLC-success fee at the `dust_buffer_feerate`
+	- outgoing HTLCs inferior to the counterparty's `dust_limit_satoshis` plus the HTLC-timeout fee at the `dust_buffer_feerate`
+	- waiting-a-counterparty-RAA-to-be-removed outgoing HTLCs inferior to the counterparty's `dust_limit_satoshis` plus the HTLC-timoeut fee at the `dust_buffer_feerate`
+
 ### Adding an HTLC: `update_add_htlc`
 
 Either node can send `update_add_htlc` to offer an HTLC to the other,