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

lightningd: add watchman storage and persistence skeleton

Public commit record

What the developer wrote

Authored by Sangbida Chaudhuri

73/100 · Adequate
lightningd: add watchman storage and persistence skeleton

Introduce the minimal storage scaffolding for the watchman module:

- db_set_blobvar / db_get_blobvar helpers for persisting binary
values (e.g. block hashes) in the SQL `vars` table.
- load_tip(): recover last_processed_height and last_processed_hash
from the wallet db.
- apply_rescan(): honour --rescan by adjusting the loaded tip
downward (negative = absolute height, positive = N blocks back).
- watchman_new(): allocate the struct, initialise the pending-op
array, and call load_tip + apply_rescan.

Wire the watchman field into struct lightningd via a forward
declaration; instantiation at startup lands in a later commit
along with the rest of the wiring.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds the first pieces of a new 'watchman' subsystem in Core Lightning. It creates helper functions to save and load binary data (like block hashes) from the wallet database, reads the last processed blockchain height/hash at startup, and applies the existing --rescan option to move the starting height backward if requested. The watchman object is declared in the main daemon structure but is not yet created or used anywhere. There is no user-facing functionality or active network behavior in this commit.

Recommended action

No security action required. Treat as normal feature scaffolding. Reviewers may want to verify in follow-up commits that apply_rescan cannot be tricked into an upward rescan and that db_get_blobvar blob length is validated before memcpy, but those concerns are outside the scope of this skeleton commit.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 12/100

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