Monero Subaddress: How Private Is It?
Subaddresses are not stealth addresses, and confusing the two has cost more than one careless operator their entire bag. A Monero subaddress is a derived, one-way construction: your primary view key and spend key generate an infinite tree of lookalike addresses that all resolve back to the same wallet control. The privacy gain is real but narrow, and the failure modes are brutal if you misunderstand where the boundary sits.
The Key Derivation Nobody Bothers to Read
Here is the actual machine. Your primary address is a pair of public keys — view and spend. A subaddress is generated by hashing the primary spend public key with an index integer, producing a scalar that is added to the spend key and hashed again to spawn a fresh pair of public keys. The critical detail: the spend private key stays identical. Only the public-facing pair rotates. That means an auditor holding your view key plus a single subaddress index can reconstruct the whole family. Anyone who tells you subaddresses are isolated wallets is either lying or has never opened the source. 🔍
On the sender side, the transaction output is locked to the subaddress's one-time public key, and the amount is wrapped in a RingCT commitment. The receiver scans with the primary view key and decodes which subaddress index matched. So far, so clean.
Where Subaddress Privacy Actually Holds
Against an external chain observer, Monero subaddress privacy is strong. The address on the wire shares no prefix, no checksum pattern, and no visible linkage to the primary. A blockchain analyst scraping outputs cannot cluster two subaddresses to one owner without either the view key or a timing-and-amount correlation attack that requires enormous volume. Ring signatures of size 16 bury the true input, and RingCT hides values by default. For a merchant rotating a fresh deposit address per customer, this is the correct tool and it works. 💪
The trap is reuse. Receive twice at the same subaddress and you have reintroduced a stable identifier into the graph. The protocol does not stop you. Nothing in the wallet UI screams at you. You simply hand the analyst a repeatable anchor and the whole subaddress privacy claim collapses into a clustering problem they have already solved for Bitcoin.
The View Key Leak Is the Real Killer
Hand your view key to a payment processor for reconciliation and you have just surrendered the index map. Every subaddress you ever generated becomes linkable to its siblings because the derivation is deterministic and public. This is not a bug; it is the design. The view key is read-only for spending but fully read-write for linkage. Audit your counterparties before you export it, or run a watch-only setup with a hard index cap. 🛡️
Amount and Timing Are Still Exposed
Subaddresses do nothing about the metadata sitting outside the cryptography. A deposit that lands at 03:14 UTC in a 0.4 XMR chunk, followed by a sweep to an exchange hot wallet at 03:20, is a fingerprint no amount of key rotation erases. Chain analysts do not break RingCT for this — they do not have to. They build behavioral graphs from sweep timing, fee selection patterns, and the node broadcast origin. Subaddress rotation is necessary and nowhere near sufficient.
Run your own node. Rotate indices aggressively. Never publish a view key without a written scope. And treat every on-chain action as if the whole ledger is public, because it is — the cryptography buys you unlinkability at the output layer, and nothing more.