From 341ec844f13c0c0abc4fe849059fbb98173f9766 Mon Sep 17 00:00:00 2001 From: eugene Date: Wed, 16 Mar 2022 13:25:50 -0400 Subject: [PATCH] BOLT#02: clarify coop close requirements This commit ensures closing_signed can only begin if there are no dangling commitments. It also clarifies update_fee requirements if it is sent after shutdown. --- 02-peer-protocol.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index d2063e5c8..e0bb5c4da 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -605,8 +605,9 @@ A sending node: - MUST NOT send a `shutdown`. - MUST NOT send multiple `shutdown` messages. - MUST NOT send an `update_add_htlc` after a `shutdown`. - - if no HTLCs remain in either commitment transaction: - - MUST NOT send any `update` message after a `shutdown`. + - if no HTLCs remain in either commitment transaction (including dust HTLCs) + and neither side has a pending `revoke_and_ack` to send: + - MUST NOT send any `update` message after that point. - SHOULD fail to route any HTLC added after it has sent `shutdown`. - if it sent a non-zero-length `shutdown_scriptpubkey` in `open_channel` or `accept_channel`: - MUST send the same value in `scriptpubkey`. @@ -638,10 +639,13 @@ shutdown starts, the question of how to behave if it wasn't is avoided: the sender always sends a `commitment_signed` first. As shutdown implies a desire to terminate, it implies that no new -HTLCs will be added or accepted. Once any HTLCs are cleared, the peer -may immediately begin closing negotiation, so we ban further updates -to the commitment transaction (in particular, `update_fee` would be -possible otherwise). +HTLCs will be added or accepted. Once any HTLCs are cleared, there are no commitments +for which a revocation is owed, and all updates are included on both commitment +transactions, the peer may immediately begin closing negotiation, so we ban further +updates to the commitment transaction (in particular, `update_fee` would be +possible otherwise). However, while there are HTLCs on the commitment transaction, +the initiator may find it desirable to increase the feerate as there may be pending +HTLCs on the commitment which could timeout. The `scriptpubkey` forms include only standard segwit forms accepted by the Bitcoin network, which ensures the resulting transaction will @@ -660,8 +664,9 @@ The `shutdown` response requirement implies that the node sends `commitment_sign ### Closing Negotiation: `closing_signed` -Once shutdown is complete and the channel is empty of HTLCs, the final -current commitment transactions will have no HTLCs, and closing fee +Once shutdown is complete, the channel is empty of HTLCs, there are no commitments +for which a revocation is owed, and all updates are included on both commitments, +the final current commitment transactions will have no HTLCs, and closing fee negotiation begins. The funder chooses a fee it thinks is fair, and signs the closing transaction with the `scriptpubkey` fields from the `shutdown` messages (along with its chosen fee) and sends the signature;