Allow HTLC receiver to dip into channel reserve

When an HTLC is added, the size of the commitment transaction increases
while that HTLC is pending, which also increases the on-chain fee that
the channel initiator must deduce from its main output.

Before sending an HTLC, when we're not the channel initiator, we thus
must ensure that our peer has enough balance to pay for the increased
commitment transaction fee. We previously went further than that, and
also required that our peer stayed above their channel reserve.

That additional requirement was unnecessary, and there was no matching
receiver-side requirement, so it should be safe to delete.

It makes a lot of sense to allow the HTLC receiver to dip into its
channel reserve to pay the fee for an HTLC they're receiving, because
this HTLC will either:

- be failed, in which case the balance goes back above channel reserve
- be fulfilled, in which case the balance increases which also helps
  meet the channel reserve

This also prevents channels from being stuck if the reserve becomes
dynamic (which will be the case with splicing). Without that change,
we can end up in a situation where most of the channel funds are on
the non-initiator side, but they cannot send HTLCs because that would
make the initiator dip into their reserve to pay the increased fee.

Since this effectively shrinks the channel initiator's reserve, the
sender must ensure that the resulting reserve is still large enough
to incentivize the initiator to behave honestly (for example by
allowing only X% of the channel reserve to be used for fees).

Author: t-bast

02-peer-protocol.md

@@ -1015,10 +1015,11 @@ A sending node:
     buffer" can handle twice the current `feerate_per_kw` to ensure predictability
     between implementations.
   - if it is _not responsible_ for paying the Bitcoin fee:
-    - SHOULD NOT offer `amount_msat` if, once the remote node adds that HTLC to
-    its commitment transaction, it cannot pay the fee for the updated local or
-    remote transaction at the current `feerate_per_kw` while maintaining its
-    channel reserve.
+    - MAY offer `amount_msat` where, once the remote node adds that HTLC to its
+    commitment transaction, it goes below its channel reserve to pay the fee for
+    the updated local or remote transaction at the current `feerate_per_kw`. The
+    sending node should limit how much of the channel reserve can be used to pay
+    the fee to ensure that the receiving node always has some funds at stake.
   - MUST offer `amount_msat` greater than 0.
   - MUST NOT offer `amount_msat` below the receiving node's `htlc_minimum_msat`
   - MUST set `cltv_expiry` less than 500000000.
@@ -1094,6 +1095,14 @@ maintaining its channel reserve (because of the increased weight of the
 commitment transaction), resulting in a degraded channel. See [#728](https://github.com/lightningnetwork/lightning-rfc/issues/728)
 for more details.
 
+When the node _responsible_ for paying the Bitcoin fee is below or just
+slightly above its channel reserve, the other node may allow it to dip
+into the channel reserve to pay the fee for an incoming HTLC. This is
+effectively the same as temporarily shrinking the channel reserve. The
+node _not responsible_ for paying the Bitcoin fee must ensure that the
+effective channel reserve is still large enough to incentivize the other
+node to behave honestly.
+
 ### Removing an HTLC: `update_fulfill_htlc`, `update_fail_htlc`, and `update_fail_malformed_htlc`
 
 For simplicity, a node can only remove HTLCs added by the other node.