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

bwatch: fire blockdepth notifications per block

Public commit record

What the developer wrote

Authored by Sangbida Chaudhuri

80/100 · Strong
bwatch: fire blockdepth notifications per block

Subdaemons like channel_open and onchaind care about confirmation
depth, not the underlying tx. Walk blockdepth_watches on every new
block and send watch_found with the current depth to each owner.

This is what keeps bwatch awake in environments like Greenlight,
where we'd otherwise prefer to hibernate: as long as something is
waiting on a confirmation milestone, the blockdepth watch holds the
poll open; once it's deleted, we're free to sleep again.

Depth fires before the per-tx scan so restart-marker watches get a
chance to spin up subdaemons before any outpoint hits land for the
same block. Watches whose start_block is ahead of the tip are stale
(reorged-away, awaiting delete) and skipped.
✓ 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 commit adds a new internal notification path in Core Lightning's block-watching plugin. It makes the plugin send a depth update to other parts of the node every time a new block arrives, so components waiting for confirmation milestones (like channel-close handling) wake up on time. The change itself is a feature/fix for reliability in hibernating environments such as Greenlight, not a patch for an externally reported security vulnerability. There is no evidence in the commit or supplied references of an exploitable weakness.

Recommended action

Review as normal code-quality/feature change. No urgent security action is indicated by the commit itself. If deploying, monitor for any regressions in subdaemon restart timing or duplicate watch_found notifications.

Security signals we found

01

New RPC-style notification path added (watch_found with depth + blockheight, no tx)

02

Explicit handling of stale watches after reorg (start_block > new_height skipped)

03

Ordering change: depth notifications fire before per-tx scan to avoid race with subdaemon startup

04

No input validation changes, no bounds checks beyond the existing depth arithmetic

05

No CVE, advisory, or security-relevant commit message language present

Risk score

Why this scored 23/100

Our methodology →
Potential impact 5/30
Exploitability 0/25
Stealth signal 3/15
Affected reach 5/15
Confidence 7/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.