AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 26 Bitcoin

bwatch: trigger rescan when a watch is added behind tip

Public commit record

What the developer wrote

Authored by Sangbida Chaudhuri

85/100 · Strong
bwatch: trigger rescan when a watch is added behind tip

bwatch_add_watch returns the watch it created (or found); each
addwatch RPC now passes that into add_watch_and_maybe_rescan,
which:

- returns success immediately if start_block > current_height
(the watch only cares about future blocks), and
- otherwise calls bwatch_start_rescan over
[start_block, current_height] for that one watch and leaves
the RPC pending until the rescan completes.

This lets callers add a watch for an event that already confirmed
(e.g. a channel funding tx some blocks back) and still get a
watch_found.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This change fixes a functional gap in Core Lightning's block watcher plugin. Previously, if you asked the node to watch for a transaction or output that had already been confirmed in the past, the watch would be recorded but the node would not look back through old blocks to find it. Now, when a watch is added for a starting block at or behind the current chain tip, the plugin automatically triggers a rescan over the relevant historical range for that specific watch, and keeps the RPC call pending until the rescan finishes. This is a correctness/reliability improvement rather than a typical security vulnerability patch.

Recommended action

Treat as a normal reliability/correctness fix. Review related commits to confirm bwatch_start_rescan handles duplicate or overlapping rescans safely, and ensure RPC pending state does not create a denial-of-service vector if many historical watches are added rapidly. No urgent security response is indicated by this diff alone.

Security signals we found

01

Functional correctness fix for missed on-chain event notifications

02

Potential reliability impact on channel funding detection and closing transaction detection

03

No explicit security boundary crossed; no input validation, auth, or crypto changes

04

RPC now blocks until historical rescan completes, changing latency/DoS surface slightly

Risk score

Why this scored 26/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 5/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.