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

lightningd: replay pending ops on plugin ready

Public commit record

What the developer wrote

Authored by Sangbida Chaudhuri

68/100 · Adequate
lightningd: replay pending ops on plugin ready

Both bwatch and watchman must be crash-resistant: a watch_send or an
add_watch/del_watch op may be in flight when lightningd crashes, and
neither side is allowed to lose it. We solve this by persisting every
pending op to the datastore in enqueue_op and dropping it from the
datastore in watchman_ack. On startup load_pending_ops rebuilds the
in-memory queue from the datastore, and watchman_on_plugin_ready
replays it once bwatch reaches INIT_COMPLETE.

watchman_add cancels any prior add for the same owner; watchman_del
cancels any pending add for the same owner before queueing the
delete. This keeps the queue from accumulating stale or
self-cancelling op pairs across restarts.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit makes the bitcoin 'watchman' subsystem crash-resistant. Previously, if the lightning node crashed while telling its external plugin to add or remove a watch on a bitcoin address, that instruction could be lost. Now each pending instruction is saved to the database, reloaded on startup, and resent once the plugin is ready again. It also cancels stale paired requests (e.g. a pending 'add' is dropped if a matching 'del' arrives). This is a reliability/robustness improvement rather than a fix for an active exploit.

Recommended action

Review as normal defensive hardening. Verify that db_save occurs before send_to_bwatch so an in-flight crash cannot lose an operation, and that watchman_ack removes both the in-memory entry and the datastore entry atomically. Confirm that the unused save_tip helper is intentional and will be wired in a follow-up. No urgent security patch is indicated.

Security signals we found

01

Crash-recovery hardening for plugin RPC operations

02

Datastore persistence of pending operations

03

Replay of pending operations on plugin readiness

04

Deduplication/cancellation of stale add/del pairs across restarts

05

Malformed datastore keys are skipped with a log_broken warning

Risk score

Why this scored 31/100

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