Removed requirement to broadcast an outdated commitment transaction

If a node has to fail a channel but knows that its latest commitment transaction is outdated it should not be required to send it but rather wait for the peer to unilaterally close the channel. The proposed solution is not so clean because it might produce a deadlock in which two peers assume they have outdated state and send `error` back and forth without actually force closing. Maybe in such a scenario we could create a protocol that mutually closes with split balance? Also replaced the word use with broadcast as it seems more accurate.
lightning · Dec 5, 2021 · fdd791a · fdd791a
1 parent 6458473
commit fdd791a
Showing 1 changed file with 7 additions and 3 deletions.
diff --git a/05-onchain.md b/05-onchain.md
@@ -143,12 +143,16 @@ A node:
       sufficient fee:
         - SHOULD use this fee to perform a *mutual close*.
       - otherwise:
-        - MUST use the *last commitment transaction*, for which it has a
+      	- if the node knows or assumes its channel state is outdated it
+      	  -  MUST NOT broadcast its *last commitment transaction*. 
+      	  -  SHOULD send an `error`.
+        - otherwise:
+          - MUST broadcast the *last commitment transaction*, for which it has a
         signature, to perform a *unilateral close*.
-      - MUST spend any `to_local_anchor` output, providing sufficient fees as incentive to include the commitment transaction in a block
+          - MUST spend any `to_local_anchor` output, providing sufficient fees as incentive to include the commitment transaction in a block
         Special care must be taken when spending to a third-party, because this re-introduces the vulnerability that was
         addressed by adding the CSV delay to the non-anchor outputs.
-	    - SHOULD use [replace-by-fee](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) or other mechanism on the spending transaction if it proves insufficient for timely inclusion in a block.
+          - SHOULD use [replace-by-fee](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) or other mechanism on the spending transaction if it proves insufficient for timely inclusion in a block.
 
 ## Rationale