fixup! Simplified retransmission rules for funding_locked.

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

02-peer-protocol.md

@@ -948,11 +948,6 @@ On reconnection, if a channel is in an error state, the node SHOULD
 retransmit the error packet and ignore any other packets for that
 channel, and the following requirements do not apply.
 
-On reconnection, a node MUST retransmit `funding_locked` unless it has
-received an `update_` or `revoke_and_ack` for that channel, otherwise
-it MAY retransmit `funding_locked`.  On reconnection, a node MUST ignore
-a redundant `funding_locked` if it receives one.
-
 On reconnection, a node MUST transmit `channel_reestablish`
 for each channel, and MUST wait for to receive the other node's
 `channel_reestablish` message before sending any other messages for
@@ -961,6 +956,11 @@ commitment number of the next `commitment_signed` it expects to receive, and
 MUST set `next_remote_revocation_number` to the commitment number of the
 next `revoke_and_ack` message it expects to receive.
 
+If `next_local_commitment_number` is 1 in both the `channel_reestablish` it
+sent and received, then the node MUST retransmit `funding_locked`, otherwise
+it MUST NOT. On reconnection, a node MUST ignore a redundant `funding_locked`
+if it receives one.
+
 If `next_local_commitment_number` is equal to the commitment number of
 the last `commitment_signed` message the receiving node has sent, it
 MUST reuse the same commitment number for its next `commitment_signed`,
@@ -1002,8 +1002,6 @@ channel altogether.
 
 There is similarly no acknowledgment for `closing_signed`, or
 `shutdown`, so they are also retransmitted on reconnection.
-`funding_locked` is implicitly acknowledged by the start of normal
-operation, but for simplicity can simply be always retransmitted.
 
 The handling of updates is similarly atomic: if the commit is not
 acknowledged (or wasn't sent) the updates are re-sent.  However, we
@@ -1020,6 +1018,11 @@ commitment number 0 is created during opening.
 `commitment_signed` for commitment number 1 is received, at which
 point the revocation for commitment number 0 is sent.
 
+`funding_locked` is implicitly acknowledged by the start of normal
+operation, which we know has begun once a `commitment_signed` has been
+received, thus the test for a `next_local_commitment_number` greater
+than 1.
+
 A previous draft insisted that the funder "MUST remember ...if it has
 broadcast the funding transaction, otherwise it MUST NOT": this was in
 fact an impossible requirement, as a node must either first commit to