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

bwatch: persist watches

Public commit record

What the developer wrote

Authored by Sangbida Chaudhuri

51/100 · Thin
bwatch: persist watches

Each watch (and its set of owners) is serialized through the wire
format from the earlier commit and stored in the datastore. On startup
we walk each type's prefix and reload the watches into their
respective hash tables, so a restart resumes watching the same things
without anyone re-registering.
✓ Subject identifies a change✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a save-and-reload feature for the bwatch plugin so that after a restart it remembers which Bitcoin transactions, outputs, and channel IDs it was monitoring. It stores these in the node's internal datastore and reads them back on startup. There is no obvious security bug in the change, but it is a new persistence mechanism that could affect reliability and, if misused, could let a stale or incorrect watch live longer than intended.

Recommended action

Review callers of bwatch_save_watch_to_datastore and bwatch_delete_watch_from_datastore to ensure every add/remove is paired correctly, avoiding orphaned or missing watches. Verify that datastore access controls prevent unauthorized modification of ["bwatch", ...] keys. Consider adding a version field or checksum to the persisted wire format to detect tampering or incompatible schema changes.

Security signals we found

01

New persistence surface introduced in a plugin (bwatch)

02

Datastore keys derived from user-controlled watch keys (scriptPubKey, outpoint, SCID, block depth)

03

Serialized watch records stored as hex blobs and parsed with fromwire on restart

04

Type mismatch and malformed SCID are filtered during reload, but other corrupt/stale records are silently skipped via `continue`

05

No explicit integrity/authenticity mechanism for stored watch records beyond datastore access control

Risk score

Why this scored 18/100

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