diff --git a/02-peer-protocol.md b/02-peer-protocol.md
index 972dc5e14..03585fc86 100644
--- a/02-peer-protocol.md
+++ b/02-peer-protocol.md
@@ -263,14 +263,25 @@ The sender MUST wait until the funding transaction has reached
 `minimum-depth` before sending this message.  The sender MUST encode
 the block position of the funding transaction into `channel-id`.  If
 the sender has already received `funding_locked` from the other node,
-it MUST fail the channel if its own `channel-id` does not match the
-received.  The sender MUST set `next-per-commitment-point` to the
+and its own `channel-id` does not match that received, it MUST either
+fail the channel or ignore the `funding_locked` message.  If it
+ignores the `funding_locked` message it MUST re-transmit
+`funding_locked` if the `channel-id` changes, otherwise it MAY
+re-transmit `funding_locked` if the `channel-id` changes.
+
+The sender MUST set `next-per-commitment-point` to the
 per-commitment point to be used for the following commitment
 transaction, derived as specified in
 [BOLT #3](03-transactions.md#per-commitment-secret-requirements).
 
-If the recipient has already sent `funding_locked` it MUST fail the
-channel if `channel-id` does not match the `channel-id` it sent.
+If the recipient has already sent `funding_locked` with `channel-id`
+which does not match the `channel-id` it sent, it MUST either fail the
+channel or ignore the `funding_locked` message.    If it
+ignores the `funding_locked` message it MUST re-transmit
+`funding_locked` if the `channel-id` changes, otherwise it MAY
+re-transmit `funding_locked` if the `channel-id` changes.
+If the recipient has received previous `funding_locked` message, it
+MUST ignore it in favor of the new `funding_locked`.
 
 The sender MUST set `announcement-node-signature` and `announcement-bitcoin-signature` to the signatures for the
 `channel_announcement` message, or all zeroes if it does not want the
@@ -280,6 +291,19 @@ The recipient SHOULD fail the channel if the `announcement-node-signature` and `
 The recipient SHOULD queue the `channel_announcement` message for its
 peers if it has sent and received a non-zero `announcement-node-signature` and `announcement-bitcoin-signature`.
 
+#### Rationale
+
+If the `minimum-depth` is very low (such as 1), it's possible that
+both nodes see different blocks containing the transaction: current
+evidence suggests that this would happen once every three days.  Thus
+there are two modes: one in which we simply fail, should that happen,
+and a more flexible mode in which nodes wait for updated
+`funding_locked` if there's disagreement.  In this mode, we require
+that they send updates to avoid relying on timeouts.
+
+Such waiting is optional, as it is extremely unlikely for
+`minimum-depth` values of 2 or more.
+
 #### Future
 
 We could add an SPV proof, and route block hashes in separate