Allow invalid contribution error upon quiescence
What the developer wrote
Authored by Wilmer Paulino
Allow invalid contribution error upon quiescence
While a contribution may be valid at the time the splice is requested,
quiescence still needs to happen, which can affect the balances of the
channel as it fully settles all pending state. After doing so, it's
possible that the contribution is no longer valid. Since quiescence
itself doesn't have a terminal message, we see a `WarnAndDisconnect`
event happen.
What changed, and why it matters
This commit updates a fuzz test (a randomized testing harness) to accept one additional warning message when the test framework expects a peer disconnection. The new message, 'contribution no longer valid at quiescence,' is treated as a normal, non-fatal outcome of the splicing/RBF protocol when channel balances settle before the splice proceeds. It is a test-only change and does not alter production code behavior.
No immediate action required. Treat as a test-maintenance commit. Review the underlying production splicing/RBF quiescence logic separately if concerned about protocol robustness, but this patch itself does not introduce or fix a security vulnerability.
Security signals we found
Fuzz-test-only change
Relates to Lightning splicing/RBF protocol quiescence handling
WarnAndDisconnect event is expected behavior, not a crash or assertion failure
No privilege escalation, asset loss, or remote code execution path evident
Evidence from the diff
The diff modifies fuzz/src/chanmon_consistency.rs, adding a second allowed substring to is_quiescent_msg in an assertion that validates disconnect-with-warning events. Previously only ‘already sent splice_locked, cannot RBF’ was accepted as a quiescence-related disconnect reason; now ‘contribution no longer valid at quiescence’ is also accepted. This aligns the fuzz harness with a production behavior where a splice contribution can become invalid after quiescence settles pending channel state, resulting in a WarnAndDisconnect event. No production logic is changed.
Changed components
fuzz/src/chanmon_consistency.rsInspect captured patch +2 / −1
diff --git a/fuzz/src/chanmon_consistency.rs b/fuzz/src/chanmon_consistency.rs
index 94111ed..3450faf 100644
--- a/fuzz/src/chanmon_consistency.rs
+++ b/fuzz/src/chanmon_consistency.rs
@@ -942,7 +942,8 @@ fn assert_disconnect_action<'a>(
msgs::ErrorAction::DisconnectPeerWithWarning { ref msg } => {
// Since sending/receiving messages may be delayed, `timer_tick_occurred` may cause
// a node to disconnect their counterparty if they're expecting a timely response.
- let is_quiescent_msg = msg.data.contains("already sent splice_locked, cannot RBF");
+ let is_quiescent_msg = msg.data.contains("already sent splice_locked, cannot RBF")
+ || msg.data.contains("contribution no longer valid at quiescence");
assert!(
msg.data.contains("Disconnecting due to timeout awaiting response")
|| is_quiescent_msg,
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.