Panic on unexpected chanmon monitor events
What the developer wrote
Authored by Joost Jager
Panic on unexpected chanmon monitor events
Monitor event draining expects BumpTransaction events, which the
harness must mine, plus SpendableOutputs and DiscardFunding events,
which it intentionally ignores because it does not model an external
wallet. Make that whitelist explicit by panicking on any other monitor
event instead of silently ignoring it.
What changed, and why it matters
This change only affects an internal fuzz-testing harness, not production code. It makes the test harness crash with a clear error message if it encounters a ChannelMonitor event it doesn't know how to handle, instead of silently ignoring it. This helps fuzz tests catch unexpected behavior but does not create a security vulnerability in real Lightning nodes.
No security action required. Treat as a normal test-quality improvement. Reviewers may verify the panic message is helpful for fuzz triage.
Security signals we found
Test harness hardening only
No production code path modified
No cryptographic, network, or state-machine logic changed
Panic is in fuzz target, not runtime node
Evidence from the diff
In fuzz/src/chanmon_consistency.rs, the HarnessNode::process_monitor_pending_events callback was changed from silently ignoring all non-BumpTransaction monitor events to explicitly handling BumpTransaction, SpendableOutputs, and DiscardFunding, and panicking on any other event. This is a test-harness-only change that improves fuzzing coverage and fail-fast behavior. It does not alter production channel monitor logic, consensus rules, or network-facing code.
Changed components
fuzz/src/chanmon_consistency.rsFuzz test harness for ChannelMonitor consistencyInspect captured patch +9 / −3
diff --git a/fuzz/src/chanmon_consistency.rs b/fuzz/src/chanmon_consistency.rs
index c8444a9..bc89551 100644
--- a/fuzz/src/chanmon_consistency.rs
+++ b/fuzz/src/chanmon_consistency.rs
@@ -1425,15 +1425,21 @@ impl<'a> HarnessNode<'a> {
// Drains raw ChannelMonitor events. Monitor-generated BumpTransaction events
// do not flow through the manager event queue but still produce transactions
- // the harness must mine.
+ // the harness must mine. SpendableOutputs and DiscardFunding may also surface
+ // here, but the harness does not model an external sweeper wallet.
fn process_monitor_pending_events(&self) -> bool {
// process_pending_events takes an Fn handler, so use interior mutability
// to report whether the callback saw anything.
let had_events = Cell::new(false);
self.monitor.process_pending_events(&|event: events::Event| {
had_events.set(true);
- if let events::Event::BumpTransaction(ref bump) = event {
- self.bump_tx_handler.handle_event(bump);
+ match event {
+ events::Event::BumpTransaction(bump) => {
+ self.bump_tx_handler.handle_event(&bump);
+ },
+ events::Event::SpendableOutputs { .. } => {},
+ events::Event::DiscardFunding { .. } => {},
+ event => panic!("Unhandled monitor event: {:?}", event),
}
Ok(())
});
Why this scored 18/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.