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