Abstract
Ring signatures allow a signer to produce a valid signature on behalf of an ad-hoc group without revealing which specific member signed. Unlike threshold signatures, no group setup ceremony is required - any signer can assemble a ring of public keys from the ledger, sign, and the verifier learns only that one member of that ring signed. This property has made ring signatures the foundational privacy primitive in Monero and a key component in several newer confidential-transaction proposals, but it comes with a concrete anonymity-versus-efficiency tradeoff that protocol designers must navigate carefully.
How Ring Signatures Work
The most widely deployed construction is the Spontaneous Anonymous Group (SAG) scheme, which Monero uses in a modified form called Multilayer Linkable Spontaneous Anonymous Group (MLSAG). A signer selects a decoy set of previously used output keys from the blockchain - effectively borrowing ring members from the UTXO set - and uses their private key together with the public keys of decoys to produce a signature where the verifier cannot distinguish the real signer from any decoy. The linkability tag (key image) is a deterministic function of the private key, so double-spending produces a collision on the key image even though the actual key is never revealed. Monero upgraded from MLSAG to CLSAG (Compact Linkable Spontaneous Anonymous Group) in 2020, reducing the per-input proof size by roughly 25% without sacrificing the linkability or unforgeability properties.
Ring Size and the Anonymity Set
Anonymity in ring signatures is directly tied to the ring size - the number of public keys in the ring, including the real signer. With a ring size of 11 (Monero’s enforced minimum as of late 2025), heuristic chain analysis can still probabilistically identify the real input under certain spending patterns, particularly when outputs are spent quickly after receiving them, reducing the pool of plausible decoys with similar age characteristics. Research from groups including Chainalysis and academic papers from Princeton and Carnegie Mellon has quantified this attack surface. Protocol responses include enforcing larger minimum ring sizes, restricting decoy selection to outputs within a similar block-age window, and integrating ring signatures with Pedersen commitments to hide amounts simultaneously - the combination Monero calls RingCT.
Tradeoffs Versus Alternative Privacy Constructions
Compared to Zcash’s Sapling and Orchard shielded pools, which use zk-SNARKs for sender and amount privacy with a global anonymity set, ring signatures scale linearly: each additional ring member adds roughly one group element and one scalar to the signature. This makes large rings expensive on-chain, capping practical anonymity sets in the hundreds rather than the thousands available to a global shielded pool. On the other hand, ring signatures need no trusted setup and no proving-key download, which lowers the barrier for client implementations. Projects like Seraphis, a proposed Monero protocol upgrade, aim to preserve the no-trusted-setup property while improving scalability and composability by replacing MLSAG/CLSAG with a new signing framework based on concise linkable ring signatures over Curve25519.
Implementation Considerations
Library support for ring signatures remains sparse compared to ECDSA or EdDSA. The Monero project maintains a C++ implementation in monero-project/monero that is well-audited but not designed for embedding in other systems. The triptych-rs Rust crate implements the Triptych construction, a logarithmic-size linkable ring signature scheme, and is usable outside Monero. When integrating any ring signature scheme, implementers should verify that their decoy selection algorithm produces a statistically uniform sample from the eligible UTXO set, since biased selection is the most common source of de-anonymization in practice.