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

bwatch: notify watchman on block_processed

Public commit record

What the developer wrote

Authored by Sangbida Chaudhuri

68/100 · Adequate
bwatch: notify watchman on block_processed

After bwatch persists a new tip, send a block_processed RPC to watchman
(lightningd) with the height and hash. bwatch only continues polling
for the next block once watchman has acknowledged that it has also
processed the new block height on its end.

This matters for crash safety: on restart we treat watchman's height as
the floor and re-fetch anything above it, so any block we acted on must
be visible to watchman before we move on.

If watchman isn't ready yet (e.g. lightningd still booting) the RPC
errors out non-fatally; we just reschedule and retry.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit hardens crash recovery in Core Lightning's new block-watching plugin (bwatch). Previously, bwatch would immediately fetch the next Bitcoin block after saving one. Now it waits for lightningd's 'watchman' component to confirm it has also recorded the same block height before continuing. This prevents a situation where bwatch moves ahead of the main daemon, so if the node crashes and restarts, no block that bwatch acted on is invisible to the rest of the system.

Recommended action

No immediate action required. This is a defensive correctness fix. Operators and downstream integrators should ensure they run a version containing this commit if using the bwatch plugin, and monitor logs for 'block_processed RPC failed (watchman not ready?)' messages during startup to confirm graceful retry behavior.

Security signals we found

01

Crash-safety / recovery race condition addressed

02

Cross-component state synchronization added

03

Non-fatal retry on RPC failure to avoid startup deadlock or busy-loop

Risk score

Why this scored 26/100

Our methodology →
Potential impact 5/30
Exploitability 2/25
Stealth signal 3/15
Affected reach 4/15
Confidence 8/10
Evidence quality 4/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.