Monero Privacy: Ring Signatures, Stealth Addresses, RingCT and Wallet Setup
Monero (XMR) is the leading privacy-focused cryptocurrency, designed from the ground up to provide strong guarantees of transaction confidentiality, sender anonymity, and receiver unlinkability. Unlike Bitcoin, where every transaction is permanently visible on a public blockchain with transparent amounts and linkable addresses, Monero employs a suite of cryptographic techniques that make it practically infeasible to determine who sent a transaction, who received it, or how much was transferred. Launched in April 2014 as a fork of the Bytecoin codebase (itself based on the CryptoNote protocol), Monero has undergone continuous development and multiple protocol upgrades to strengthen its privacy guarantees. This article provides a detailed technical examination of Monero's privacy mechanisms, including ring signatures, stealth addresses, Ring Confidential Transactions (RingCT), Bulletproofs, the Dandelion++ protocol, comparisons with Bitcoin's privacy model, atomic swaps, and practical guidance for wallet setup and usage.
Why Privacy Matters in Cryptocurrency
The fundamental problem with transparent blockchains like Bitcoin is that they create a permanent, immutable record of every financial transaction. While Bitcoin addresses are pseudonymous (not directly tied to real-world identities), the deterministic relationship between transactions creates a rich graph that blockchain analysis companies can exploit. Companies like Chainalysis and Elliptic have built sophisticated tools that can trace the flow of funds across thousands of transactions, cluster addresses belonging to the same entity, and link pseudonymous addresses to real-world identities through exchange KYC data, known addresses, and heuristic analysis. Once a single address in a cluster is identified, the entire transaction history of that entity becomes transparent.
This lack of privacy has concrete consequences. A merchant who accepts Bitcoin can see exactly how much money is in their customer's wallet. An employer who pays in Bitcoin can see what their employees spend their salary on. A political donor's contributions are visible to anyone. Monero was designed to prevent all of these scenarios by making privacy the default, mandatory behavior rather than an optional feature. The official Monero website provides an accessible overview of these privacy goals.
Ring Signatures: Sender Privacy
Ring signatures are the primary mechanism by which Monero obscures the identity of the transaction sender. A ring signature is a cryptographic signature that can be produced by any member of a group (the "ring") such that it is computationally infeasible to determine which member actually produced the signature. In Monero's implementation, when a user spends funds, their real transaction output (the "real spend") is mixed with a set of decoy outputs selected from the blockchain. The resulting ring signature proves that one of the outputs in the ring was spent, but it is impossible to determine which one.
How Ring Signatures Work in Monero
When constructing a transaction, the Monero wallet selects the real output being spent along with a number of decoy outputs (called "mixins" or "ring members"). As of the current protocol, the mandatory ring size is 16, meaning each transaction input includes 1 real spend and 15 decoys, for a total of 16 possible signers. The wallet uses a carefully designed selection algorithm that mimics the statistical distribution of real spend ages -- recent outputs are more likely to be selected as decoys because real spends tend to be recent, ensuring that the decoy distribution matches the real spend distribution and preventing statistical distinguishability.
The mathematical foundation is based on a linkable ring signature scheme. The "linkable" property is critical: it prevents double-spending by generating a unique key image for each output that is deterministically derived from the output's private key. When a transaction is published, the key image is recorded on the blockchain. If anyone attempts to spend the same output again, the duplicate key image will be detected and the transaction rejected. Importantly, the key image reveals nothing about which ring member produced it -- it only allows detection of duplicate spends.
Evolution of Ring Size
Monero's mandatory ring size has increased over time as research revealed that smaller rings provided insufficient anonymity. Early Monero transactions allowed ring sizes as small as 1 (no mixing at all), which obviously provided no sender privacy. The minimum was gradually increased to 3, then 7, then 11, and currently stands at 16. Each increase strengthens the anonymity set but also increases transaction size and computational cost. The Monero Research Lab continuously evaluates the tradeoffs and has published extensive analysis of optimal ring sizes. The project's research-driven approach is reflected in its comprehensive documentation at Moneropedia.
Stealth Addresses: Receiver Privacy
While ring signatures protect the sender, stealth addresses protect the receiver. In Bitcoin, if you give someone your address, they can look it up on the blockchain and see every transaction ever received by that address. Monero solves this problem through one-time stealth addresses: for every transaction, the sender generates a unique, one-time address on behalf of the receiver, derived from the receiver's public address using Diffie-Hellman key exchange. This one-time address appears on the blockchain, but it cannot be linked to the receiver's published address by anyone other than the sender and receiver.
The Stealth Address Protocol
A Monero public address consists of two public keys: the public view key (A) and the public spend key (B). When a sender wants to pay this address, they generate a random scalar r, compute a shared secret using the Diffie-Hellman exchange with the receiver's public view key, and derive a one-time public key P = H(rA)G + B, where H is a hash function and G is the generator point of the elliptic curve. The sender includes the value rG (the transaction public key) in the transaction. The receiver, who knows the private view key a, can compute aR = a(rG) = r(aG) = rA (the same shared secret) and check every transaction output to see if it is addressed to them. The receiver can then compute the corresponding private key to spend the output: x = H(aR) + b, where b is the private spend key.
This protocol means that even if two people send Monero to the same address, the outputs that appear on the blockchain are completely different and unlinkable. An outside observer cannot determine that two transactions were sent to the same recipient. The receiver can share their public view key with an auditor who needs to verify incoming payments without granting the ability to spend funds or see outgoing transactions.
RingCT: Hiding Transaction Amounts
Ring Confidential Transactions (RingCT), activated on the Monero network in January 2017, hide the amounts transferred in every transaction. Before RingCT, Monero transaction amounts were visible on the blockchain, which compromised privacy by allowing observers to trace funds based on amount matching. RingCT uses Pedersen commitments to cryptographically commit to transaction amounts without revealing them, combined with range proofs that verify the committed amounts are non-negative (preventing the creation of money from nothing through negative amounts).
Pedersen Commitments
A Pedersen commitment to an amount v with blinding factor r is computed as C = rG + vH, where G and H are generator points with an unknown discrete logarithm relationship. This commitment is perfectly hiding (reveals nothing about v) and computationally binding (the committer cannot change v after committing). For a transaction to be valid, the sum of input commitments must equal the sum of output commitments plus the transaction fee commitment. Because Pedersen commitments are additively homomorphic, this balance can be verified without knowing any of the actual amounts: (r1*G + v1*H) - (r2*G + v2*H) - (r3*G + v3*H) = (r1 - r2 - r3)*G + (v1 - v2 - v3)*H. If the transaction is balanced (v1 = v2 + v3), the value component cancels out, and the verifier only needs to confirm that the remaining point is a valid commitment to zero.
Bulletproofs and Bulletproofs+
Range proofs are necessary to prevent a sender from committing to a negative amount, which would effectively create money from nothing while still satisfying the commitment balance equation. Monero originally used Borromean ring signatures for range proofs, but these were replaced by Bulletproofs in October 2018 and subsequently by Bulletproofs+ in August 2022. Bulletproofs are a non-interactive zero-knowledge proof system that proves a committed value lies within a specified range (0 to 2^64 - 1) without revealing the value. The key advantage of Bulletproofs over the previous scheme is dramatically smaller proof sizes: a Bulletproof for a single output is approximately 0.7 KB compared to 13 KB for the Borromean range proof, an 18x reduction. Bulletproofs+ further improved efficiency by approximately 6%. The source code implementing these cryptographic constructions is available in the Monero repository on GitHub.
Dandelion++: Network-Level Privacy
Even with perfect on-chain privacy, the act of broadcasting a transaction to the network can reveal information. When a node broadcasts a transaction, network observers can use timing analysis to determine which node originated the transaction, potentially linking the transaction to an IP address. Dandelion++ is a protocol-level defense against this attack, implemented in Monero to obscure the originating node of a transaction.
Dandelion++ operates in two phases. In the "stem" phase, the transaction is forwarded along a random path through the network, passing from one node to the next without being broadcast to all peers. After a random number of hops (determined probabilistically), the transaction enters the "fluff" phase, where it is broadcast normally through standard gossip propagation. By the time the transaction is visible to the network at large, it appears to originate from the node where the stem phase ended, not from the true originator. This provides plausible deniability for the sender's IP address. For additional network-level privacy, users should route their Monero wallet's traffic through Tor or I2P.
Comparison with Bitcoin Privacy
Bitcoin's privacy model relies entirely on pseudonymity: addresses are not directly tied to identities, but the transaction graph is fully public. Several techniques have been developed to improve Bitcoin privacy, including CoinJoin (multiple users combine their transactions into a single transaction with multiple inputs and outputs), PayJoin (the sender and receiver both contribute inputs, breaking the common-input-ownership heuristic), and the Lightning Network (which moves transactions off-chain). However, all of these are optional, require active user participation, and have been shown to be partially defeatable by sophisticated analysis.
Key Differences
The fundamental difference is that Monero's privacy is mandatory and protocol-enforced. Every Monero transaction uses ring signatures, stealth addresses, and RingCT regardless of the sender's preferences. This creates a uniform anonymity set: even if a particular user does not care about privacy, their transaction looks identical to every other transaction on the network, which protects those who do care about privacy. In Bitcoin, the use of privacy-enhancing techniques is visible on-chain and can actually draw attention to transactions.
Bitcoin's UTXO (Unspent Transaction Output) model creates a transaction graph that can be analyzed through heuristics such as common input ownership (inputs to the same transaction are likely controlled by the same entity), change address detection (one output returns change to the sender), and round number analysis (a payment is more likely to be a round number). Monero's combination of ring signatures, stealth addresses, and hidden amounts defeats all of these heuristics simultaneously.
Atomic Swaps
Atomic swaps enable the trustless exchange of one cryptocurrency for another without requiring a centralized exchange. Monero-Bitcoin atomic swaps are particularly significant because they allow users to convert between the transparent Bitcoin ledger and Monero's private ledger without passing through a KYC-regulated exchange. The swap protocol uses cryptographic techniques including adaptor signatures and hash time-locked contracts (HTLCs) to ensure that either both parties receive their funds or neither does, with no possibility of one party cheating the other.
The COMIT Network developed an implementation of Monero-Bitcoin atomic swaps, available at github.com/comit-network/xmr-btc-swap. The protocol works as follows: Alice (who has BTC) and Bob (who has XMR) agree on an exchange rate. Bob locks his XMR in a transaction that can be spent by Alice if she reveals a secret, or refunded to Bob after a timeout. Alice locks her BTC in a similar construct. Alice claims the XMR by revealing the secret, which allows Bob to claim the BTC. The protocol is designed so that neither party can steal the other's funds.
# Install the swap CLI tool
# Download from GitHub releases page
wget https://github.com/comit-network/xmr-btc-swap/releases/latest/download/swap
# Make executable
chmod +x swap
# List available sellers (market makers providing XMR liquidity)
./swap list-sellers --rendezvous-point /dnsaddr/rendezvous.coblox.tech/p2p/...
# Execute a swap (buy XMR with BTC)
./swap buy-xmr --receive-address YOUR_XMR_ADDRESS --change-address YOUR_BTC_CHANGE_ADDRESS --seller SELLER_MULTIADDR
Wallet Setup and Best Practices
Choosing and configuring a Monero wallet correctly is essential for realizing the privacy benefits of the protocol. The official Monero GUI and CLI wallets, maintained by the Monero core team, are the most trusted options. Third-party wallets like Feather Wallet (for desktop) and Cake Wallet (for mobile) provide additional features and usability improvements while maintaining strong privacy defaults.
Official CLI Wallet Setup
The Monero CLI wallet provides the most control and is recommended for users who prioritize security and privacy. Installation on Linux involves downloading the official binaries, verifying their GPG signatures, and running the daemon and wallet software:
# Download and verify Monero CLI
wget https://downloads.getmonero.org/cli/linux64
# Verify the SHA256 hash against the official hashes page
# Extract
tar -xvf linux64
# Start the Monero daemon (full node)
./monerod --detach
# Create a new wallet
./monero-wallet-cli --generate-new-wallet=/path/to/wallet
# Restore from seed phrase (25 words)
./monero-wallet-cli --restore-deterministic-wallet --restore-height BLOCK_HEIGHT
# Connect through Tor (using torsocks)
torsocks ./monerod --anonymous-inbound YOUR_ONION:18083,127.0.0.1:18083,16
torsocks ./monero-wallet-cli --wallet-file /path/to/wallet --daemon-address 127.0.0.1:18081
Running a Full Node over Tor
For maximum privacy, run a full Monero node rather than relying on remote nodes. A remote node can observe your transaction submission patterns, your IP address, and the outputs you query (which reveals which outputs are real spends rather than decoys). Running your own node eliminates this vulnerability. Routing the node's traffic through Tor prevents your ISP from knowing that you are running Monero software. The Monero user guides provide step-by-step instructions for various configurations.
For operational security practices that complement cryptocurrency privacy, see our OPSEC fundamentals guide. Understanding onion routing is also valuable for configuring Tor-routed Monero nodes correctly.
Subaddresses
Monero subaddresses provide an additional layer of receiver privacy. A single Monero wallet can generate an unlimited number of subaddresses, each of which is cryptographically unlinkable to the main address or to other subaddresses. This allows users to give a unique subaddress to each sender or service, preventing any two senders from knowing they are paying the same recipient. If a subaddress is compromised or linked to your identity, you can simply stop using it without affecting your other subaddresses or your main address. Subaddresses also provide accounting benefits, as the wallet tracks incoming funds per subaddress.
Advanced Privacy Features
View Keys and Selective Transparency
Monero supports selective transparency through view keys. The private view key allows its holder to see all incoming transactions to the wallet but not outgoing transactions or the wallet's balance (since outputs spent through ring signatures are indistinguishable from those that remain unspent from the view key's perspective alone). This is useful for auditing, tax compliance, or proving that a payment was received. A per-transaction proof can also be generated to prove that a specific payment was sent, without revealing any other transaction history.
Seraphis and Jamtis: The Next Generation
The Monero Research Lab is actively developing Seraphis, a next-generation transaction protocol that will replace the current RingCT scheme. Seraphis is designed to support much larger ring sizes (potentially 128 or more), a more flexible address scheme called Jamtis that supports forward secrecy and improved multi-signature workflows, and membership proofs that scale logarithmically with ring size rather than linearly. Seraphis represents the most significant protocol upgrade in Monero's history and is expected to substantially strengthen its privacy guarantees when deployed.
Risks and Limitations
No privacy system is perfect, and it is important to understand Monero's limitations. While the on-chain privacy is strong, off-chain metadata can still compromise anonymity. Purchasing Monero through a KYC exchange links your identity to a known set of outputs. Using a remote node reveals your IP address and query patterns to the node operator. Sending Monero to a known address (such as an exchange deposit address) creates a point of deanonymization even though the transaction itself is private on-chain.
Statistical analysis of ring signatures, while not able to definitively identify the real spend, can sometimes reduce the anonymity set by identifying decoys that are provably not the real spend (for example, if a decoy has already been provably spent in another transaction with a ring size of 1 from the early blockchain history). The Monero community has addressed this through mandatory minimum ring sizes and the removal of the option for no-mix transactions, but historical data from the early blockchain remains a concern for very old outputs. Research papers such as "An Empirical Analysis of Traceability in the Monero Blockchain" have examined these issues, and the Monero community has responded with protocol improvements addressing each identified weakness.
For comprehensive privacy in cryptocurrency transactions, the combination of Monero's protocol-level privacy with network-level anonymity (through Tor or I2P), careful operational security, and awareness of metadata leakage provides the strongest available protection. Monero is a tool, not a complete solution, and its effectiveness depends entirely on how it is used within a broader security strategy.