Imagine you run a small privacy-focused consultancy in Boston and accept Monero (XMR) for client payments. You hand a prospective client a single address printed on your website and later see funds arrive — but you don’t want anyone (client, IRS auditor with subpoena, or an over-eager on-chain analyst) to stitch those payments together and learn how much you earned. For Monero users who need that kind of compartmentalization, “stealth addresses” are the core technical tool that makes single-wallet, multi-recipient privacy practical. They aren’t magic; they are a specific cryptographic pattern with clear advantages, costs, and operational rules that matter in everyday use.
This explainer walks through the mechanism behind stealth addresses, how they interact with wallet choices (GUI, CLI, mobile), and the trade-offs that affect real-world privacy in the US context: when to run a local node, how subaddresses relate to stealth outputs, what the restore-height and view-only modes change for auditors, and what common misconceptions about anonymity actually miss the point.
Mechanism first: what a stealth address does and how Monero implements it
At its simplest, a stealth address is a way for a sender to create a one-time destination on the recipient’s behalf without publishing a reusable public key. In Monero, the recipient publishes a single public address (actually a pair of public keys). When somebody sends funds, the sender uses those public keys and fresh randomness to produce a unique one-use public output key for that payment. Only the recipient, who holds the corresponding private keys, can recognize and spend that output. Since every transaction output looks like a fresh address on-chain, linkability between outputs is severely reduced.
Monero layers stealth outputs on top of ring signatures and RingCT (confidential amounts). Together they mean: (1) output ownership is hidden by stealth addresses; (2) input sets are obfuscated by ring signatures so a given output can’t be cleanly traced back to its source; and (3) amounts are hidden by RingCT. The important mechanism-level takeaway: stealth addresses hide “where funds went” by making per-payment addresses indistinguishable, but they do not eliminate all operational metadata (IP addresses, wallet synchronization patterns, or seed compromise) that can leak identity.
How stealth addresses interact with real wallets and user choices
Knowing the cryptography is useful, but privacy in practice depends on wallet architecture and user behavior. Monero offers several wallet kinds: the official GUI (Simple Mode and Advanced Mode), the CLI wallet for power users, and third-party local-sync wallets like Cake Wallet, Feather, and Monerujo. Each choice affects how stealth-address protections combine with network-level and device-level privacy.
For example, the GUI in Simple Mode connects to a remote node: you still get per-payment stealth outputs, but your node queries go through a third-party server that sees which outputs you scan for. If you prioritize the strongest possible anonymity in the US — where subpoenaed remote node logs could be an operational risk — run a local node (Advanced Mode or CLI). Local nodes download the blockchain and, if disk space is limited, support pruning to cut storage to roughly 30GB while maintaining full verification properties relevant to identifying stealth outputs.
Another relevant feature is subaddresses. They are distinct from stealth addresses conceptually: subaddresses let you generate many public receiving addresses that are all tied to the same wallet and seed; stealth output generation still creates one-time output keys for each incoming payment. Using subaddresses for different clients or revenue streams adds a metadata layer that prevents simple reuse-based linking, and it’s recommended for the compartmentalization scenario described above.
Restore height, view-only wallets, and auditing — practical operations that affect privacy
Wallet recovery and auditing interact with stealth addresses in operational ways. When restoring a wallet from a 25-word mnemonic seed, the restore height determines the block at which the wallet begins scanning for outputs. Setting this correctly speeds synchronization and reduces unnecessary network chatter that could be observed by a remote node. For privacy-minded users: if you restore and re-scan from block zero on a remote node, you’ll leak the fact you own outputs across a long time range. So set a sensible restore height (approximate first-use block) when recovering — it’s a simple operational habit with material privacy impact.
View-only wallets (created from the private view key) show incoming stealth outputs without ability to spend. That’s useful for accountants or auditors: they can verify receipts without holding spend keys. But a view-only wallet combined with an untrusted remote node can leak viewing patterns. For better guarantees, keep the view-only file offline or use it only with a trusted local node.
Limits, adversaries, and the remaining attack surface
Stealth addresses buy you strong on-chain unlinkability but they don’t defend against every threat. Consider three realistic adversary classes and what stealth addressing does and doesn’t prevent:
1) Passive chain observer: stealth outputs plus RingCT largely prevent chain-based reconstruction of which outputs belong to the same user. For this adversary, Monero’s default privacy is effective.
2) Network-level observer (ISP, Wi‑fi snooper, or a malicious remote node operator): if you connect without Tor/I2P and use a remote node, your IP and node query patterns expose linking signals. Monero supports Tor and I2P integration in both GUI and CLI; routing node RPC traffic over anonymizing networks significantly reduces this risk.
3) Host compromise or seed exposure: a stolen 25-word seed or a compromised hardware wallet nullifies stealth protections. Hardware wallet integration (Ledger, Trezor models listed in wallet docs) and standard hygiene (offline seed backup, verify downloads via SHA256 and GPG signatures) are the only defenses here. This is a boundary condition: cryptographic privacy mechanisms don’t matter if keys are extracted.
Common misconceptions clarified
Misconception: “If Monero uses stealth addresses, I don’t need subaddresses or Tor.” Not true. Stealth addresses prevent simple on-chain linking of payments, but subaddresses help operationally segregate receipts (for accounting and minimizing correlation from reuse), and Tor mitigates network-level deanonymization risks. They are complementary, not redundant.
Misconception: “Remote nodes are fine because the chain still conceals amounts.” While amounts are hidden by RingCT, a remote node learns which outputs your wallet scans and when you scan them — that metadata can be revealing. The privacy trade-off between convenience and exposure should guide the decision to use a local node versus a remote node.
Decision-useful heuristics: when to prioritize which trade-offs
– Convenience-first (beginners, small balances): use the official GUI in Simple Mode with a trusted remote node, enable subaddresses for different clients, and verify downloads. This is reasonable for low-risk everyday use, but be explicit that privacy is reduced relative to a local node setup.
– Strong anonymity (receiving repeat payments, high-sensitivity work): run a local node (Advanced Mode or CLI), use subaddresses per payer, route traffic over Tor/I2P, and keep the 25-word seed offline in a hardware-backed backup. Consider view-only wallets for third-party audits rather than sharing seeds.
– Mobile and on-the-go: choose community-vetted local-sync wallets like Cake, Feather, or Monerujo (they protect private keys by scanning locally). Use the restore height when installing on a new device to reduce network leakage and speed sync.
What to watch next — practical signals and forward-looking implications
Monero’s privacy stack is stable, but operational privacy evolves around tooling and infrastructure. Watch for: improvements in light-wallet privacy that reduce remote-node metadata leaks; audits or tooling that simplify secure restore-height selection; and broader ecosystem developments (wallet UX that nudges users toward Tor or local nodes). Any changes that make private-by-default behaviors easier will materially increase real-world anonymity for typical US users.
If you want hands-on practice with privacy-preserving wallet options and verified downloads, the Monero project resources and wallets list are a useful start; see monero for official downloads and documentation.
FAQ
Q: Are stealth addresses unique to Monero?
A: The stealth-address idea exists in other privacy systems, but Monero combines it with ring signatures and confidential transactions so that each output is a one-time key, amounts are hidden, and input sets are obfuscated. The specific combination and default privacy posture are characteristic of Monero.
Q: If I use a remote node, can I still rely on stealth addresses?
A: Stealth addresses will still hide on-chain linkage, but a remote node can observe which outputs your wallet scans and when. That metadata can be exploited, so for high-stakes privacy you should prefer a local node or route RPC calls over Tor/I2P.
Q: How should I choose a restore height when recovering a wallet?
A: Pick the block height from around the date you first used the wallet or received your earliest expected payment. This reduces unnecessary scanning and metadata exposure. If in doubt, err slightly earlier rather than starting from genesis, but avoid re-scanning decades of blocks unless you run a trusted local node.
Q: Can multisignature wallets and stealth addresses coexist?
A: Yes. Monero supports multisig, and transactions still use one-time output keys for incoming funds. Multisig adds an operational layer (co-signers, partial transaction exchange) that can affect privacy if co-signers are adversarial, so trust and protocols between parties matter.
Q: What is the single biggest operational mistake that reduces stealth-address privacy?
A: Exposing the seed (25-word mnemonic), using an unverified or compromised wallet binary, or connecting without network-layer anonymity to an untrusted remote node are the primary failure modes. Cryptography cannot protect keys that are leaked or hosts that are compromised.