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

wallet: Update the max_index cache when issuing new addresses

Public commit record

What the developer wrote

Authored by Christian Decker

73/100 · Adequate
wallet: Update the max_index cache when issuing new addresses

The write-through cache added for the address max_index was only kept in
sync in wallet_can_spend(). wallet_get_newindex() still read and wrote
the bip32_max_index/bip86_max_index db vars directly, leaving the
in-memory cache stale after every newaddr. Since listaddresses and the
rescan window now read from that cache, freshly issued addresses were
invisible until the next restart (and wallet_can_spend could even write a
stale, lower value back to the db).

Route all reads and writes through wallet_max_addr_index() and
wallet_set_max_addr_index() so the cache and the db never diverge.

Changelog-None
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug where Core Lightning's in-memory record of the highest address index could fall out of step with the database. When a user generated a new on-chain address, the code updated the database directly but left the cached value unchanged. That meant newly created addresses would not show up in address lists or rescan windows until the node was restarted, and in some cases the stale cache could overwrite the newer database value with an older one. The patch routes all reads and writes through helper functions so the cache and database stay synchronized.

Recommended action

Apply the patch. Nodes that have already generated addresses while running affected code should be restarted after upgrading so the cache is rebuilt from the database at startup, and operators should verify that expected addresses appear in `listaddresses` and on-chain rescans.

Security signals we found

01

Cache/database inconsistency in address index tracking

02

Potential for stale lower index to overwrite newer persisted index

03

Freshly generated addresses invisible to wallet rescan/listing until restart

04

Could cause missed on-chain funds or incorrect address gap handling

Risk score

Why this scored 51/100

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