Persisting the sent-sweep watermark means a relaunch runs a windowed sweep,
which can't see a change made outside the GUI (a Console z_importviewingkey,
an external same-seed restore) that adds an old send below the window. This
adds a periodic full re-sweep so that case is still caught within ~7 days.
- sentSweepSafetyNetDue(now, lastFull) = lastFull > 0 && now - lastFull > 7d
(a wallet that has never full-swept doesn't trigger one; the seeding sweep
records the time). lastFullTime / lastFullHeight ride in the sent_sweep
snapshot; any successful full sweep (seed, verify-mismatch or safety-net)
resets the clock. On load, a valid watermark without a clock starts it now,
so even watermarks seeded before this field eventually re-sweep.
- When due, the snapshot forces a full sweep for that cycle. Gated on: a
watermark exists, a routine (non-syncing) cycle, not the Mining page, and
not in full-sweep backoff -- so a full sweep that can't finish on a slow
daemon backs off instead of retrying every cycle.
Degrades gracefully: ~0.4 s on a note-cache daemon; callLong(120 s) with
backoff on an old one (the deferred banding would keep each cs_main hold
short so it fits there too). Helper + persistence covered by tests.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
z_listsentbyaddress re-walks the whole wallet when there's no usable
watermark, which the daemon does under cs_main for every send -- hundreds
of seconds, 400+ s and ~19 GB RSS on a large wallet. The watermark lived
only in memory, so every relaunch, reconnect or daemon restart paid for a
full sweep. This persists it so those cases run a bounded windowed sweep
([z, 0, 2, tip - W + margin]) instead (SENT-HISTORY-SWEEP Part 1).
- The watermark (W = last swept tip), its anchor (A = W - margin) and anchor
hash (H_A = getblockhash(A)), plus the enrichment backlog and the full-
sweep backoff, ride in the encrypted history snapshot as an optional
`sent_sweep` object (schema stays v1; a missing/inconsistent one reads as
"no watermark" = today's behaviour, so older builds and payloads are safe).
- Before the first windowed sweep after a load, the anchor is verified
(getblockhash(A) == H_A). A match means any fork is inside the window; a
mismatch (reorg deeper than the margin, different chain/datadir) or an
inability to check drops the watermark and sweeps the whole wallet.
- The first sweep after a load uses a bigger margin (absorbs notifier lag),
and a watermark older than 2400 blocks uses the long timeout (callLong).
- The backlog is persisted WITH W: a pure z->z send's txid lives only in a
sweep result and would be lost if the window moved past an un-enriched one.
- Watermark changes reach disk (folded into the store signature), and every
hard case still forces a full sweep: reorg (anchor verify), GUI rescan /
zap / import / address change, restoreOriginalWallet, and disconnect.
Deferred (follow-ups, each only turns a correct-but-slow case faster, never a
correctness risk): the banded full sweep for seeding on a pre-note-cache
daemon, the external-import tripwire, and the weekly safety-net re-sweep.
Part 2 (the daemon's decrypt cost) is already on the daemon's
perf/sapling-note-cache branch.
Pure helpers + cache round-trip + anchor-verify/large-window covered by
tests; the getblockhash-after-sweep updates the pinned RPC sequences.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Opening the transaction-history cache always derived its encryption key
with Argon2id, even for an unencrypted wallet. For those wallets the
passphrase is just a value derivable from the database itself, so the
~50-100 ms Argon2id stall bought no additional secrecy and ran on the
UI thread at open.
- Unencrypted wallets now derive the cache key with a cheap,
domain-separated BLAKE2b KDF over the wallet identity, keyed by the
per-wallet salt. The secret is derivable from the DB, so this is
security-equivalent for the unencrypted case and avoids the stall.
- Passphrase-encrypted wallets are unchanged: they keep the Argon2id
key derivation. The two paths use separate domain labels, so the
fast-path key and the Argon2id key never collide for the same DB and
salt; a cache written under one cannot be read under the other.
Tests cover the fast-path round-trip and reopen, and assert that an
Argon2id unlock of the same DB produces a different key and fails to
read the fast-path snapshot.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The tx-history cache was only ever used from the UI thread and had no
locking. To let snapshots be written from a background thread:
- every SQL statement runs under one database mutex and the key fields
under a second one, taken after it and never held across I/O or the
key derivation;
- a write is a self-contained, move-only SnapshotJob holding the rows
and a private copy of the key, which is wiped after the write or when
a job never runs; the JSON build and encryption hold no lock;
- a job with an all-zero key is refused instead of overwriting a good
snapshot with one nobody can read;
- the prune after a write also keeps the wallet unlocked now, so a late
job for the previous wallet can't delete the salt of the one just
switched to;
- keyId() gives a non-reversible tag of the installed key, so a
passphrase change can be told from a re-unlock with the same one.
replace() stays a synchronous wrapper with the same result. A failed
INSERT is now logged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Write vault.dat atomically and 0600 (it holds the PIN-encrypted passphrase, so
a world-readable copy enables an offline brute-force of the short PIN), and
chmod the tx-history SQLite + its WAL/SHM sidecars to 0600 on open.
- The tx-history snapshot and key-salt rows are keyed on a hash of the full
address set, which changes whenever a new address is generated — orphaning the
prior hash's full-history blob and salt forever. pruneOtherWallets() now drops
rows for every non-live wallet hash on each save, bounding the database.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add an encrypted SQLite transaction history cache with cached tip metadata and
per-address shielded scan progress so startup and full refreshes avoid
re-scanning every z-address while still invalidating on wallet/address/rescan
changes.
Improve wallet history loading by paging transparent transactions, preserving
cached shielded and sent rows, keeping recent/unconfirmed activity visible, and
classifying mining-address receives. Show z_sendmany opid sends immediately in
History and Overview, pin pending rows through refreshes, and apply optimistic
address/balance debits until opids resolve.
Add timestamped RPC console tracing by source/method without logging params or
results, reduce redundant refresh/RPC calls, and cache Explorer recent block
summaries in SQLite.
Expand focused tests for transaction cache encryption, scan-progress
persistence/invalidation, history preservation, operation-status parsing,
pending send visibility, and Explorer/RPC refresh behavior.
DanSandClaude Opus 4.8