From 55ac90c6b6fc974650f7337c9acb44bc8d9ce67a Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Mon, 3 Jul 2017 12:16:37 +0930 Subject: [PATCH 1/2] BOLT 2: don't require revoke_and_ack rexmit if it's bogus. If we've completed shutdown, you must have received revoke_and_ack, so don't require us to re-xmit in that case. Signed-off-by: Rusty Russell --- 02-peer-protocol.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index f01362d6c..5e5629e6f 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -980,7 +980,7 @@ last `commitment_signed` message the receiving node has sent, it SHOULD fail the channel. If `next_remote_revocation_number` is equal to the commitment number of -the last `revoke_and_ack` the receiving node has sent, it MUST re-send +the last `revoke_and_ack` the receiving node has sent and the receiving node has not already received a `closing_signed`, it MUST re-send the `revoke_and_ack`, otherwise if `next_remote_revocation_number` is not equal to one greater than the commitment number of the last `revoke_and_ack` the receiving node has sent (or equal to zero if none have been sent), it SHOULD fail the channel. @@ -1023,6 +1023,11 @@ write to disk by the sender upon each transmission, whereas the scheme here encourages a single persistent write to disk for each `commitment_signed` sent or received. +We should never be asked to retransmit `revoke_and_ack` if we've +received a `closing_signed`, since that implies we've completed +shutdown which can only happen once the `revoke_and_ack` was received +by the remote node. + Note that the `next_local_commitment_number` starts at 1 since commitment number 0 is created during opening. `next_remote_revocation_number` will be 0 until the From 975fcdf3b47fb79d0520446215b0569bb40e6fdd Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Mon, 3 Jul 2017 12:17:34 +0930 Subject: [PATCH 2/2] BOLT 2: don't require shutdown re-xmit if we're doing closing_signd rexmit. closing_signed means we've completed shutdown, which means the other side knows. Signed-off-by: Rusty Russell --- 02-peer-protocol.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 5e5629e6f..83466c4d8 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -992,9 +992,9 @@ transaction is broadcast by the other side at any time. This is particularly important if a node does not simply retransmit the exact same `update_` messages as previously sent. -On reconnection if the node has sent a previous `shutdown` it MUST -retransmit it, and if the node has sent a previous `closing_signed` it -MUST then retransmit the last `closing_signed`. +On reconnection if the node has sent a previous `closing_signed` it +MUST then retransmit the last `closing_signed`, otherwise if the node +has sent a previous `shutdown` it MUST retransmit it. ### Rationale @@ -1011,8 +1011,8 @@ polite to retransmit before disconnecting again, but it's not a MUST because there are also occasions where a node can simply forget the channel altogether. -There is similarly no acknowledgment for `closing_signed`, or -`shutdown`, so they are also retransmitted on reconnection. +`closing_signed` can only be sent after `shutdown`, so only one needs +to be retransmitted on reconnection. The handling of updates is similarly atomic: if the commit is not acknowledged (or wasn't sent) the updates are re-sent. However, we