Use more specific locked_handle_unfunded_close when possible
What the developer wrote
Authored by Joost Jager
Use more specific locked_handle_unfunded_close when possible
What changed, and why it matters
This commit is a small internal cleanup in the Lightning Dev Kit's channel manager. It replaces calls to a more general force-close helper with a more specific helper meant for channels that have not yet been funded. The change removes duplicated parameters and makes the code clearer, but there is no direct evidence in the commit or supplied references that it fixes an active security vulnerability or changes externally observable behavior.
Treat as a routine refactor. If a security concern is suspected, review the implementation of locked_handle_unfunded_close to confirm it preserves the same invariants as the previous locked_handle_force_close path for unfunded channels, particularly around monitor-update tracking and error-message suppression.
Security signals we found
Refactor only: no new input validation, no privilege boundary change, no cryptographic change
No mention of vulnerability, CVE, security bug, or exploit in commit message or diff
No verified references supplied
Change is internal to channel state-machine cleanup logic
Evidence from the diff
The patch refactors three call sites in lightning/src/ln/channelmanager.rs to use self.locked_handle_unfunded_close(err, &mut chan) instead of self.locked_handle_force_close(…, &mut peer_state.closed_channel_monitor_update_ids, &mut peer_state.in_flight_monitor_updates, err, &mut chan). The new helper appears intended for unfunded-channel closures and omits monitor-update tracking parameters. The commit message frames this as ‘use more specific … when possible,’ i.e., a code-quality/consistency change. No functional bug, exploit primitive, or security impact is described or directly visible in the diff.
Changed components
lightning/src/ln/channelmanager.rsChannel close logic for unfunded channelsInspect captured patch +3 / −16
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index a1bf543..f2419b2 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -4225,13 +4225,7 @@ where
let reason = ClosureReason::LocallyCoopClosedUnfundedChannel;
let err = ChannelError::Close((reason.to_string(), reason));
let mut chan = chan_entry.remove();
- let (_, mut e) = self.locked_handle_force_close(
- &mut peer_state.closed_channel_monitor_update_ids,
- &mut peer_state.in_flight_monitor_updates,
- err,
- &mut chan,
- );
-
+ let (_, mut e) = self.locked_handle_unfunded_close(err, &mut chan);
e.dont_send_error_message();
shutdown_result = Err(e);
}
@@ -8421,9 +8415,7 @@ where
let reason = ClosureReason::FundingTimedOut;
let msg = "Force-closing pending channel due to timeout awaiting establishment handshake".to_owned();
let err = ChannelError::Close((msg, reason));
- let (_, e) = self.locked_handle_force_close(
- &mut peer_state.closed_channel_monitor_update_ids,
- &mut peer_state.in_flight_monitor_updates,
+ let (_, e) = self.locked_handle_unfunded_close(
err,
chan,
);
@@ -11278,12 +11270,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
let reason = ClosureReason::CounterpartyCoopClosedUnfundedChannel;
let err = ChannelError::Close((reason.to_string(), reason));
let mut chan = chan_entry.remove();
- let (_, mut e) = self.locked_handle_force_close(
- &mut peer_state.closed_channel_monitor_update_ids,
- &mut peer_state.in_flight_monitor_updates,
- err,
- &mut chan,
- );
+ let (_, mut e) = self.locked_handle_unfunded_close(err, &mut chan);
e.dont_send_error_message();
return Err(e);
},
Why this scored 19/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.