Monero Wallet Scanning: How View Tags Cut Sync Time

Monero's privacy architecture creates a scanning problem wallets must decrypt every transaction output using private view keys to determine ownership. This brute-force approach consumes hours when synchronizing against a blockchain exceeding 220 GB. View tags merged April 20, 2022 reduce scanning time 30-40% by adding 1-byte filters that skip 99.6% of expensive cryptographic operations.

Monero addresses use two key pairs: spend keys that authorize transactions and view keys that decrypt outputs. The view key lets wallets identify incoming payments without exposing spend authority enabling watch-only wallets and payment verification without compromising fund security.

During synchronization, wallets scan every block attempting to decrypt each output using the private view key. The process derives a shared secret from the output's one-time public key and the wallet's private view key, then checks if the resulting stealth address matches. This operation repeats for every output in the blockchain millions of elliptic curve calculations that turn wallet sync into a CPU-intensive endurance test.

The scanning burden grows linearly with blockchain size. Monero generates roughly 2 million outputs monthly based on transaction volume. First-time wallet sync processes the entire history, while regular users scan only new blocks since last sync. This asymmetry punishes new users and wallets restored from seed phrases with multi-hour synchronization delays.

UkoeHB's view tag proposal optimizes scanning by adding a 1-byte tag to each output derived from the sender-receiver shared secret. Implementation uses SipHash 2-4 to hash the shared secret, extracting the first byte as the view tag.

When scanning, wallets first compare the tag byte. Matches trigger full cryptographic verification. Mismatches skip expensive operations entirely. With 256 possible byte values, random outputs match roughly 1 in 256 times creating a 0.4% false positive rate that requires verification on only matched candidates.

The optimization eliminates 99.6% of elliptic curve scalar multiplication operations during scanning. Testing showed 30-40% reduction in total synchronization time depending on hardware and blockchain state. The improvement comes purely from computational savings no network bandwidth reduction occurs since wallets still download complete blocks.

View tags add minimal overhead. Each output grows by 1 byte, increasing blockchain size roughly 0.1% annually at current transaction rates. The tag derivation during transaction creation adds negligible computational cost compared to proof generation and signing. Recipients benefit without sender performance penalty.

SipHash 2-4 selection over cn_fast_hash delivered ~1.5% performance improvement during tag comparison. The hash function choice matters because wallets execute tag checks millions of times during full sync small per-operation gains compound significantly.

The implementation introduced tx_out_to_tagged_key as a new output type replacing tx_out_to_key at fork height. A grace period permitted both output types during network transition, preventing mempool disruption as nodes upgraded. This phased deployment avoided chain splits while ensuring all new transactions benefit from view tag optimization.

Tag security relies on the shared secret remaining private. Since only sender and receiver derive this secret, third parties cannot generate valid tags preserving Monero's transaction graph obfuscation. The tag reveals no information about output value, address, or spending status beyond the binary "worth checking" signal.

Wallet developers must implement tag checking correctly to avoid security vulnerabilities. Skipping full verification on tag matches would let attackers craft transactions with matching tags pointing to incorrect addresses. The tag serves only as a filter final ownership verification still requires complete cryptographic validation. Monero-lws implements light wallet functionality by accepting view keys via REST API and scanning the blockchain on behalf of clients. This architecture shifts computational burden from user devices to dedicated servers running continuous scanning operations.

The LMDB backend stores view keys and transaction data in a memory-mapped database optimized for concurrent read operations. Servers connect to monerod instances using ZeroMQ pub/sub, receiving push notifications for new blocks instead of polling. This event-driven architecture reduces latency between block publication and wallet notification.

Light wallet servers leverage amd64 ASM acceleration from the Monero project for elliptic curve operations. Dedicated hardware and optimized code paths allow servers to scan faster than mobile wallets or browser-based clients. Webhook support enables instant notifications for incoming transactions including zero-confirmation alerts. The MyMonero API compatibility means existing wallet clients can connect without modification. Users submit view keys through REST endpoints, servers handle scanning, clients receive transaction notifications and balance updates. This architectural pattern matches how most cryptocurrency wallets operate delegating blockchain interaction to specialized infrastructure.

Light wallet servers gain full transaction visibility for submitted view keys. Operators can determine when users receive funds, amounts, sender outputs, and spending patterns. This contradicts Monero's privacy guarantees where even node operators shouldn't track individual wallet activity. Trust becomes mandatory. Users must believe that light wallet operators won't log view keys, analyze transaction patterns, or sell data to chain analysis companies. The technical architecture provides no cryptographic protection only operational security practices and privacy policies stand between user data and potential misuse.

Remote node connections share view keys with node operators who scan on behalf of wallets. This reduces local storage and CPU requirements at the cost of transaction privacy. The node operator learns user wallet contents and incoming payment timing valuable intelligence for targeted attacks or regulatory pressure.

Full-sync wallets maintain maximum privacy by downloading and scanning the entire 220+ GB blockchain locally. Nobody except the wallet owner knows which outputs belong to them. The synchronization delay and storage overhead represent the price of self-sovereign privacy requiring personal infrastructure instead of trusting third parties.

Block-level parallelization scans multiple blocks concurrently using thread pools. Each worker processes independent blocks, checking outputs against view keys without coordination overhead. This approach scales with CPU cores four cores achieve roughly 4x throughput compared to single-threaded scanning.

Output-level parallelization within blocks distributes individual output checks across threads. Since each output check operates independently, parallel processing applies cleanly without lock contention. SIMD instructions can process multiple tag comparisons simultaneously on modern CPUs with AVX2 or AVX-512 support. Cache optimization matters significantly. Sequential scanning through blockchain data maintains favorable memory access patterns. Random-access patterns during database lookups thrash CPU caches and trigger memory bandwidth saturation. Well-designed implementations batch database queries and maintain working sets that fit in L3 cache.

The synchronization process splits into blockchain download and output scanning phases. Download parallelization uses multiple peer connections to fetch blocks concurrently. Scanning parallelization distributes cryptographic work across cores. Overlapping these operations through pipelining scanning previous blocks while downloading new ones maximizes hardware utilization.

Wallets created after specific dates can configure restore heights telling the scanner to ignore blocks before wallet creation. This eliminates millions of unnecessary checks against outputs that couldn't possibly belong to recently-generated addresses.

The optimization requires accurate wallet birthdate knowledge. Conservative estimates add safety margin scanning a week earlier than actual creation catches transactions near the boundary. Aggressive estimates risk missing payments if wallet creation timing was recorded incorrectly. Exchange deposits and merchant payments create use cases requiring exact blockchain height precision. If you generated a wallet at block 2,500,000 to receive a deposit, scanning from block 2,499,000 provides margin while skipping 2.5 million earlier blocks. This turns multi-hour sync into minutes for new wallets.

Restore height becomes critical for seed phrase recovery. Users who know when they created their wallet can skip years of blockchain history. Those uncertain must scan from genesis or risk missing old transactions trading sync time for transaction recovery completeness.

Full-sync mode downloads the complete blockchain and scans locally using private view keys. Maximum privacy. Maximum resource requirements. Suitable for users with disk space and patience willing to wait hours for initial sync. Remote-node mode connects to third-party monerod instances, sharing view keys for remote scanning. Minimal local resources. Zero privacy guarantees. Appropriate when trusting specific node operators or when privacy matters less than convenience.

Light wallet mode submits view keys to dedicated scanning servers via REST APIs. Instant synchronization. Complete transaction visibility for operators. Practical for mobile wallets and browser extensions where full blockchain sync proves infeasible due to storage or bandwidth constraints.

The decision reflects threat model assessment. Users facing targeted surveillance should run full nodes with local scanning. Average users accepting metadata exposure for usability benefits choose remote or light wallet modes. No universal recommendation exists only tradeoffs between operational security and user experience.

Ring signature pruning could eliminate spent output data from historical blocks once sufficient time passes. This shrinks blockchain size and reduces scanning load, though it weakens security assumptions about ring anonymity set permanence.

Zero-knowledge proof integration might allow wallets to prove output ownership without revealing view keys to servers. This would enable light wallet functionality with cryptographic privacy protection instead of trust-based security. Hardware acceleration through GPU-based elliptic curve operations or specialized ASICs could parallelize scanning beyond CPU core limits. Mobile SoCs with neural processing units might repurpose matrix multiplication hardware for cryptographic acceleration.

View tag expansion to 2-byte or variable-length tags would reduce false positive rates below 0.4%, further decreasing verification operations. The tradeoff involves increased blockchain bloat and tag derivation complexity requiring analysis of marginal benefit versus implementation cost. First-time wallet sync determines whether users tolerate Monero or abandon it for more responsive cryptocurrencies. Multi-hour waits signal technical barriers that discourage adoption beyond privacy enthusiasts willing to endure synchronization delays.

View tags represent the largest single-feature improvement to scanning performance since Monero's launch. The 30-40% reduction brings sync time from unbearable to merely annoying meaningful progress that required no privacy tradeoffs or blockchain bloat.

The fundamental tension between privacy and performance persists. Monero's architecture inherently requires scanning work that transparent blockchains avoid. View tags optimize this scanning through clever cryptography, but cannot eliminate it entirely without compromising the privacy guarantees that justify Monero's existence. Users choose between running full nodes with local scanning or trusting third parties with view key access. This decision shapes their privacy posture and determines whether they control their financial surveillance exposure or delegate it to operators who may not share their security priorities.