Don't send init `closing_signed` too early after final HTLC removal 2023-08-shutdown-remove-early-sign
authorMatt Corallo <git@bluematt.me>
Sat, 26 Aug 2023 19:59:21 +0000 (19:59 +0000)
committerMatt Corallo <git@bluematt.me>
Sat, 11 Nov 2023 20:24:58 +0000 (20:24 +0000)
commit70b18663f40b82bce367538600d3b7d7fc1a6450
treea7d36fd60a67e6328fc9051da88ed925c9c92661
parent281a0aead744351c43fce660cf78f955fc969bfb
Don't send init `closing_signed` too early after final HTLC removal

If we remove an HTLC (or fee update), commit, and receive our
counterparty's `revoke_and_ack`, we remove all knowledge of said
HTLC (or fee update). However, the latest local commitment
transaction that we can broadcast still contains the HTLC (or old
fee), thus we are not eligible for initiating the `closing_signed`
negotiation if we're shutting down and are generally expecting a
counterparty `commitment_signed` immediately.

Because we don't have any tracking of these updates in the `Channel`
(only the `ChannelMonitor` is aware of the HTLC being in our latest
local commitment transaction), we'd previously send a
`closing_signed` too early, causing LDK<->LDK channels with an HTLC
pending towards the channel initiator at the time of `shutdown` to
always fail to cooperatively close.

To fix this race, we add an additional unpersisted bool to
`Channel` and use that to gate sending the initial `closing_signed`.
lightning/src/ln/channel.rs
lightning/src/ln/shutdown_tests.rs