From 20524d4109b6e50a7b3b54fb68086540f968d921 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Thu, 29 Nov 2018 04:32:11 +0000 Subject: [PATCH] BOLT 2: advise ping-before-commitment_signed on quiescent connections. (#508) This seems to be a cause of stuck HTLCs on the network: c-lightning has done this for a while now (since 0.6.1). [ Minor wording clarification merged --RR ] Decided-at: Adelaide Summit 2018 Signed-off-by: Rusty Russell --- 02-peer-protocol.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 3faf4a8da..f92d12c43 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -940,6 +940,8 @@ change the commitment transaction aside from the new revocation hash fee changes). - MUST include one `htlc_signature` for every HTLC transaction corresponding to BIP69 lexicographic ordering of the commitment transaction. + - if it has not recently received a message from the remote node: + - SHOULD use `ping` and await the reply `pong` before sending `commitment_signed`. A receiving node: - once all pending updates are applied: @@ -958,6 +960,13 @@ There's little point offering spam updates: it implies a bug. The `num_htlcs` field is redundant, but makes the packet length check fully self-contained. +The recommendation to require recent messages recognizes the reality +that networks are unreliable: nodes might not realize their peers are +offline until after sending `commitment_signed`. Once +`commitment_signed` is sent, the sender considers itself bound to +those HTLCs, and cannot fail the related incoming HTLCs until the +output HTLCs are fully resolved. + ### Completing the Transition to the Updated State: `revoke_and_ack` Once the recipient of `commitment_signed` checks the signature and knows