Removed requirement to broadcast an outdated commitment transaction (#942)

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.

Co-authored-by: t-bast <[email protected]>

Author: lightning-developer

02-peer-protocol.md

@@ -1405,7 +1405,7 @@ A node:
     `your_last_per_commitment_secret` is correct for that
     `next_revocation_number` minus 1:
       - MUST NOT broadcast its commitment transaction.
-      - SHOULD fail the channel.
+      - SHOULD send an `error` to request the peer to fail the channel.
     - otherwise:
       - if `your_last_per_commitment_secret` does not match the expected values:
         - SHOULD send an `error` and fail the channel.
@@ -1414,7 +1414,7 @@ A node:
     `your_last_per_commitment_secret` is correct for that
     `next_revocation_number` minus 1:
       - MUST NOT broadcast its commitment transaction.
-      - SHOULD fail the channel.
+      - SHOULD send an `error` to request the peer to fail the channel.
       - SHOULD store `my_current_per_commitment_point` to retrieve funds
         should the sending node broadcast its commitment transaction on-chain.
     - otherwise (`your_last_per_commitment_secret` or `my_current_per_commitment_point`
@@ -1490,18 +1490,19 @@ Similarly, for the fundee's `funding_signed` message: it's better to
 remember a channel that never opens (and times out) than to let the
 funder open it while the fundee has forgotten it.
 
-`option_data_loss_protect` was added to allow a node, which has somehow fallen behind
-(e.g. has been restored from old backup), to detect that it's fallen-behind. A fallen-behind
-node must know it cannot broadcast its current commitment transaction — which would lead to
-total loss of funds — as the remote node can prove it knows the
-revocation preimage. The error returned by the fallen-behind node
-(or simply the invalid numbers in the `channel_reestablish` it has
-sent) should make the other node drop its current commitment
-transaction to the chain. This will, at least, allow the fallen-behind node to recover
-non-HTLC funds, if the `my_current_per_commitment_point`
-is valid. However, this also means the fallen-behind node has revealed this
-fact (though not provably: it could be lying), and the other node could use this to
-broadcast a previous state.
+`option_data_loss_protect` was added to allow a node, which has somehow fallen
+behind (e.g. has been restored from old backup), to detect that it has fallen
+behind. A fallen-behind node must know it cannot broadcast its current
+commitment transaction — which would lead to total loss of funds — as the
+remote node can prove it knows the revocation preimage. The `error` returned by
+the fallen-behind node should make the other node drop its current commitment
+transaction to the chain. The other node should wait for that `error` to give
+the fallen-behind node an opportunity to fix its state first (e.g by restarting
+with a different backup). If the fallen-behind node doesn't have the latest
+backup, this will, at least, allow it to recover non-HTLC funds, if the
+`my_current_per_commitment_point` is valid. However, this also means the
+fallen-behind node has revealed this fact (though not provably: it could be lying),
+and the other node could use this to broadcast a previous state.
 
 `option_static_remotekey` removes the changing `to_remote` key,
 so the `my_current_per_commitment_point` is unnecessary and thus

05-onchain.md

@@ -143,12 +143,15 @@ 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
-        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
-        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.
+      	- if the node knows or assumes its channel state is outdated:
+      	  - MUST NOT broadcast its *last commitment transaction*.
+        - 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.
+          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.
 
 ## Rationale