BOLT 2: can't complete shutdown while splicing

02-peer-protocol.md

@@ -660,10 +660,13 @@ A sending node:
   - MAY send a `shutdown` before a `funding_locked`, i.e. before the funding transaction has reached `minimum_depth`.
   - if there are updates pending on the receiving node's commitment transaction:
     - MUST NOT send a `shutdown`.
+  - if there is an ongoing splice:
+    - MUST NOT send a `shutdown`.
   - MUST NOT send an `update_add_htlc` after a `shutdown`.
   - if no HTLCs remain in either commitment transaction:
 	- MUST NOT send any `update` message after a `shutdown`.
   - SHOULD fail to route any HTLC added after it has sent `shutdown`.
+  - MUST NOT initiate a new splice if none are already in progress after a `shutdown`.
   - if it sent a non-zero-length `shutdown_scriptpubkey` in `open_channel` or `accept_channel`:
     - MUST send the same value in `scriptpubkey`.
   - MUST set `scriptpubkey` in one of the following forms:
@@ -681,8 +684,9 @@ A receiving node:
     - SHOULD fail the connection.
   - if it hasn't sent a `funding_locked` yet:
     - MAY reply to a `shutdown` message with a `shutdown`
-  - once there are no outstanding updates on the peer, UNLESS it has already sent a `shutdown`:
+  - once there are no outstanding updates on the peer and no ongoing splice, UNLESS it has already sent a `shutdown`:
     - MUST reply to a `shutdown` message with a `shutdown`
+  - MUST NOT initiate a new splice if none are already in progress.
   - if both nodes advertised the `option_upfront_shutdown_script` feature, and the receiving node received a non-zero-length `shutdown_scriptpubkey` in `open_channel` or `accept_channel`, and that `shutdown_scriptpubkey` is not equal to `scriptpubkey`:
     - MUST fail the connection.
 
@@ -711,6 +715,12 @@ of the receiving node to change the `scriptpubkey`.
 
 The `shutdown` response requirement implies that the node sends `commitment_signed` to commit any outstanding changes before replying; however, it could theoretically reconnect instead, which would simply erase all outstanding uncommitted changes.
 
+`shutdown` requires that there be no splice in progress, but if there
+is already a splice in progress, it might require another splice to
+"unstick" it (if the first splice was invalid, double-spent, or simply
+had too low a fee), so in this case initiating another splice is legal
+even after sending a shutdown.
+
 ### Closing Negotiation: `closing_signed`
 
 Once shutdown is complete and the channel is empty of HTLCs, the final