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

bkpr: use list commands instead of subscribing to notifications.

Public commit record

What the developer wrote

Authored by Rusty Russell

83/100 · Strong
bkpr: use list commands instead of subscribing to notifications.

This is reliable, meaning we should never get replayed events.

We have to reference count to make sure all commands are complete,
before we return. In particular, annotating with descriptions can
involve several calls to list commands. We need to give them the
results *after* this is all complete.

test_bookkeeping_descriptions() relied on log messages from
notifications, which now only happen when a command is called. This
changes the test a bit.

Since we no longer subscribe to the balance_snapshot event, we
need to create the wallet account at initialization, as callers
expect it to exist.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit rewrites the Core Lightning bookkeeper plugin so it fetches accounting events by calling 'list' RPC commands on demand instead of listening to live event notifications. The main goal is reliability: notifications can be replayed or missed, while list commands give a consistent, ordered view. The change also adds reference counting so the plugin waits for all helper RPC calls to finish before returning results, stores the last-processed index in the datastore, and creates the wallet account at startup because it can no longer rely on a startup balance-snapshot notification.

Recommended action

Review as a defensive reliability improvement. No immediate patch deployment required for security reasons, but operators relying on bookkeeper accounting should verify correctness after upgrade, especially for nodes that were previously missing the bookkeeper plugin during channel activity. Consider whether the removed balance_snapshot recovery path covered edge cases not yet exercised by the new list-based polling.

Security signals we found

01

Elimination of notification replay/miss race conditions in accounting data

02

Addition of reference counting to prevent premature command completion during parallel RPCs

03

Persistent indexing via datastore to avoid reprocessing or skipping chain/channel moves

04

Removal of balance_snapshot notification dependency, which could arrive inconsistently

05

Test expectations changed: 'journal_entry' reconciliations replaced by direct 'invoice' events, indicating behavior change in how missed events are recovered

Risk score

Why this scored 27/100

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