Monero's Math I: Hiding Sender & Receiver

Now we cash in the toolkit. Two of Monero's three secrets — who received and who sent — are solved with nothing more exotic than the elliptic-curve arithmetic and hashes we've already built. This lesson shows the exact equations, and at each step contrasts them with what a transparent chain would publish instead. The elegance is that the same operations that name people on Bitcoin are re-pointed to hide them on Monero.

Hiding the Receiver: Stealth Addresses

On Bitcoin the receiver's address sits in the output for all to see, and every payment to it is publicly clustered. Monero instead generates a fresh one-time output key for every payment, so two payments to the same person share nothing on-chain. Recall a Monero account has public keys A = a·G (view) and B = b·G (spend). To pay you, the sender:

• picks a random scalar r and publishes the transaction public key R = r·G in the transaction;
• computes a shared secret via Diffie–Hellman and hashes it to a scalar: Hs(r·A);
• sets the output's one-time key to P = Hs(r·A)·G + B.

That P is what appears on-chain — a never-before-seen point, unlinkable to your address B. This is the same Diffie–Hellman exchange that secures web traffic, repurposed to derive an address only the two parties can compute.

How You Find and Spend Your Own Output

You scan each transaction with your view key. Because a·R = a·(r·G) = r·(a·G) = r·A, you can recompute the identical shared secret the sender used, even though you never knew r. You then test whether P − Hs(a·R)·G equals your public spend key B; if it does, the payment is yours. To spend it you need the one-time private key, which works out to x = Hs(a·R) + b — and only you know b. So the view key lets a wallet (or an auditor) detect incoming funds, while the spend key is required to move them. That clean split is a direct gift of the additive structure P = Hs(r·A)·G + B.

A Speed Note: View Tags

Scanning every output with a full elliptic-curve operation is expensive. Monero adds a view tag: one byte derived from the same shared secret Hs(a·R), stored with the output. A wallet checks the cheap one-byte tag first and discards roughly 99.6% of outputs before doing the full derivation — a pure optimization that doesn't weaken the math, only speeds the scan. It's a good reminder that real protocols layer engineering on top of the pure equations.

Hiding the Sender: Ring Signatures

Stealth addresses hide the receiver; the ring signature hides the sender. As we saw with signatures, a transparent chain's signature names the exact output being spent. Monero instead forms a ring: your real output plus a set of decoy outputs sampled from the chain's history. The signature proves "the private key of one of these ring members authorized this spend" without revealing which. A network observer sees a set of equally-plausible candidates and cannot tell the true spend from the decoys. The current scheme, CLSAG, is a compact ring signature that simultaneously proves you own the output key and the matching amount commitment, in one structure.

Stopping Double-Spends Without Naming the Output

Anonymity creates a new problem: if no one knows which output you spent, what stops you from spending it twice in two different rings? The key image solves it. For your one-time key P with private key x, the key image is

I = x · Hp(P)

where Hp is the hash-to-point map from the hashing lesson. Three properties make it work: it's deterministic (one output → exactly one image), unforgeable (you can't make a valid image without x), and unlinkable (because nobody knows the discrete log of Hp(P), the image reveals nothing about P). The network records every key image it has seen and rejects any repeat. So Monero gets Bitcoin's double-spend protection — "this coin is now spent" — without Bitcoin's transparency of which coin.

Why the Cofactor Matters Here

One implementation subtlety ties back to our curve lesson: Ed25519 has cofactor 8, so a malicious signer could try to add a small-order "torsion" point to a key image and produce several distinct valid images for one output — defeating the double-spend rule. Monero therefore validates that key images lie in the prime-order subgroup. It's a sharp example of how a privacy feature (the key image) inherits responsibilities from the exact curve chosen. With sender and receiver hidden, only the amount remains — and that needs a different trick, which is next.