BOLT 2: note splice requirements in the checks for adding HTLCs and s…

…etting fees.

Any changes must be valid for all possible commitment transactions.  A minor
change, but for implementations which quote the spec and check those quotes
this will highlight the changes needed.

Signed-off-by: Rusty Russell <[email protected]>

02-peer-protocol.md

@@ -1006,7 +1006,7 @@ A sending node:
     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
+    any of its commitment transactions, 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.
@@ -1083,6 +1083,9 @@ 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.
 
+If splicing is supported, there can be more than one commitment transaction
+at a time: proposed changes must be valid for all of them.
+
 ### 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.
@@ -1315,6 +1318,8 @@ given in [BOLT #3](03-transactions.md#fee-calculation).
 The node _responsible_ for paying the Bitcoin fee:
   - SHOULD send `update_fee` to ensure the current fee rate is sufficient (by a
       significant margin) for timely processing of the commitment transaction.
+  - MUST NOT set `feerate_per_kw` in excess of what it can afford on any of the receiving node's
+    current commitment transactions.
 
 The node _not responsible_ for paying the Bitcoin fee:
   - MUST NOT send `update_fee`.
@@ -1325,7 +1330,7 @@ A receiving node:
   - if the sender is not responsible for paying the Bitcoin fee:
     - MUST fail the channel.
   - if the sender cannot afford the new fee rate on the receiving node's
-  current commitment transaction:
+  current commitment transactions:
     - SHOULD fail the channel,
       - but MAY delay this check until the `update_fee` is committed.
 
@@ -1351,6 +1356,9 @@ it's simplest to only allow it to set fee levels; however, as the same
 fee rate applies to HTLC transactions, the receiving node must also
 care about the reasonableness of the fee.
 
+If splicing is supported, there can be more than one commitment transaction
+at a time: proposed changes must be valid for all of them.
+
 ## Message Retransmission
 
 Because communication transports are unreliable, and may need to be