Avoid stuck channels after fee increase with additional reserve (#740)

Add an additional "reserve" for funders on top of the real reserve to
avoid getting in a state where the channel is unusable because
of the increased commit tx cost of a new HTLC.

Requirements are only added for the funder sending an HTLC.
Fundee receiving HTLCs may choose to verify that funders apply
this, but it may lead to an unusable UX.

Fixes #728.

02-peer-protocol.md

@@ -806,9 +806,22 @@ is destined, is described in [BOLT #4](04-onion-routing.md).
 #### Requirements
 
 A sending node:
-  - MUST NOT offer `amount_msat` it cannot pay for in the
-remote commitment transaction at the current `feerate_per_kw` (see "Updating
-Fees") while maintaining its channel reserve.
+  - if it is _responsible_ for paying the Bitcoin fee:
+    - MUST NOT offer `amount_msat` if, after adding that HTLC to its commitment
+    transaction, it cannot pay the fee for either the local or remote commitment
+    transaction at the current `feerate_per_kw` while maintaining its channel
+    reserve (see [Updating Fees](#updating-fees-update_fee)).
+    - SHOULD NOT offer `amount_msat` if, after adding that HTLC to its commitment
+    transaction, its remaining balance doesn't allow it to pay the commitment
+    transaction fee when receiving or sending a future additional non-dust HTLC
+    while maintaining its channel reserve. It is recommended that this "fee spike
+    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.
   - 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.
@@ -875,6 +888,14 @@ seconds, and the protocol only supports an expiry in blocks.
 specification; larger amounts are not necessary, nor wise, during the
 bootstrap phase of the network.
 
+The node _responsible_ for paying the Bitcoin fee should maintain a "fee
+spike buffer" on top of its reserve to accommodate a future fee increase.
+Without this buffer, the node _responsible_ for paying the Bitcoin fee may
+reach a state where it is unable to send or receive any non-dust HTLC while
+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.
+
 ### 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.