From 240cdec2619c1abb9ae53abb1c7fdbf9dee532b5 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 | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 1779b0872..618f75669 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -544,10 +544,10 @@ A sending node: - if it hasn't sent a `funding_created` (if it is a funder) or a `funding_signed` (if it is a fundee): - MUST NOT send a `shutdown` - MAY send a `shutdown` before a `funding_locked`, i.e. before the funding transaction has reached `minimum_depth`. - - if there are updates pending on the receiving node's commitment transaction: + - if there are uncommitted updates pending on the receiving node's commitment transaction: - MUST NOT send a `shutdown`. - MUST NOT send an `update_add_htlc` after a `shutdown`. - - if no HTLCs remain in either commitment transaction: + - if neither side has a dangling commitment and neither commitment contains any HTLCs (including dust HTLCs): - MUST NOT send any `update` message after a `shutdown`. - 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`: @@ -580,10 +580,10 @@ 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 +HTLCs will be added or accepted. Once any HTLCs are cleared, there are no dangling commitments 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). +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 @@ -602,7 +602,7 @@ 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 +Once shutdown is complete, the channel is empty of HTLCs, there are no dangling commitments 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