Prevent empty commitment transactions

As suggested by @JssDWt

Author: t-bast

blip-0030.md

@@ -83,10 +83,19 @@ When receiving `accept_channel2`:
   `accept_channel2`:
   * MUST send an `error` and forget the channel
 
-When sending or receiving `update_add_htlc`:
+When sending `update_add_htlc`:
 
 * If `zero_reserve` has been negotiated:
   * MUST ignore any channel reserve standard requirement
+  * If the resulting commitment transaction would have no outputs:
+    * MUST NOT send `update_add_htlc`
+
+When receiving `update_add_htlc`:
+
+* If `zero_reserve` has been negotiated:
+  * MUST ignore any channel reserve standard requirement
+  * If the resulting commitment transaction would have no outputs:
+    * MUST send an `error` and fail the channel
 
 If the channel is not public, both nodes:
 
@@ -98,6 +107,14 @@ If the channel is not public, both nodes:
 The use of zero-reserve is symmetrical: it is either offered to both nodes or
 unused.
 
+In theory, the channel could be in a state where the commitment transaction has
+no outputs, if all of the channel liquidity is allocated to pending dust HTLCs.
+This state wouldn't make sense: all of the channel value would be burned to
+miner fees. We make sure we never get into this state. In practice though, this
+should never happen since nodes set `max_dust_htlc_exposure_msat` to ensure
+that dust HTLCs don't grow unbounded and set `max_htlc_value_in_flight_msat` to
+restrict their exposure to pending HTLCs.
+
 ### Fraud proofs
 
 If one of the nodes publishes a revoked commitment, the other node can create