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

lightningd: migrate events from bookkeeper at startup.

Public commit record

What the developer wrote

Authored by Rusty Russell

73/100 · Adequate
lightningd: migrate events from bookkeeper at startup.

We take over the --bookkeeper-dir and --bookkeeper-db options, and
then if we can find the bookkeeper db we extract the records to
initialize our chain_moves and channel_moves tables.

Of course, bookkeeper now needs to not register those options.

When bookkeeper gets invoked the first time, it will reconstruct
everything from listchannelmoves and listcoinmoves. It cannot
preserve manually-added descriptions, so we put those in the datastore
for it ready to go.

Note that the order of onchain_fee changes slightly from the original.
But this is fine.

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

What changed, and why it matters

This commit moves the bookkeeper accounting data from a separate plugin database into the main lightningd database at startup. It adds a one-time migration that reads the old accounts.sqlite3 file and copies its records into new internal tables. The change is mostly a refactor of where data lives, but it touches startup code, database migrations, and option handling. There is no direct evidence in the commit that this fixes an active security vulnerability; it appears to be architectural cleanup.

Recommended action

Treat this as a regular code-review item rather than an urgent security patch. Reviewers should verify that the migration cannot be triggered or abused via crafted legacy database files or option paths, and that the temporary chdir and external DB open do not introduce path-traversal or symlink issues. The FIXME stub for migrate_setup_coinmoves should be completed and tested before release. No immediate user action is required unless the project flags this commit as security-relevant.

Security signals we found

01

Database migration code runs at startup with full node privileges

02

Migration opens and reads an external/legacy database file path controlled by user options

03

Migration abort()s on unexpected tag strings or amount conversion failures

04

Migration calls fatal() if the legacy database version is not exactly 17

05

New code chdirs into the legacy bookkeeper directory during migration

06

User descriptions from the legacy DB are copied into the datastore without explicit length/sanitization checks visible in the diff

07

No explicit input validation on legacy DB contents beyond column type binding

Risk score

Why this scored 24/100

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