RingCT weaknesses

Where Monero's privacy is imperfect today — and why that's exactly what FCMP++ fixes

The model: effective ring size

A ring of 16 gives 16 options only if all are equally plausible. Every bit of outside information reduces the effective ring size. If an observer can cross out 10 decoys, "1 of 6" remains. If they can weigh the rest — "probably this one".

1. Chain reaction (historical)

Before 2016, transactions without decoys (ring of 1) were allowed. Such an input reveals exactly which output was spent. And if that output was used as a decoy in someone else's ring, it can be crossed out there. That may make another ring unambiguous, and so on — a chain reaction. 2017 studies showed a large share of early inputs were deanonymised this way.

Status: closed by banning zero-decoy rings and moving to RingCT (RingCT outputs mix only with RingCT outputs). But old outputs remember their history.

2. Input age

If the age distribution of decoys doesn't match how people really spend, the real input stands out. The classic "newest is real" heuristic worked very well on early transactions. Details in decoy selection.

Status: mitigated by the gamma distribution, but not fully fixable as long as decoys are chosen.

3. The EAE attack (Eve–Alice–Eve)

Eve (say, an exchange) sends money to Alice, and Alice later sends money back to Eve (the same exchange, maybe via a few intermediate transactions). Eve knows her output at the start of the chain and her output at the end. If she sees "her" output in the rings of intermediate transactions and the timing is plausible, she can link sending and receiving with high probability.

Status: one of the most practical attacks for centralised services. Mitigated by churning (sending to yourself with pauses), but reliably fixed only by FCMP++.

4. Flooding (black marble)

An attacker mass-produces transactions with their own outputs. By the decoy-selection rules, these start landing in other users' rings. The attacker knows they're "empty" and crosses them out. The bigger their share of outputs in a period, the smaller everyone else's effective ring. Spam episodes like this were seen in 2021 and 2024; estimates showed a noticeable drop in effective ring size during them.

Status: limited by cost (fees) and the dynamic block size. Eliminated by FCMP++: when the "ring" is the whole blockchain, the attacker's share is negligible.

5. Input merging

If a transaction spends 5 inputs, that's 5 rings, and the real members of all five are known to belong to one person. If an observer sees these rings contain outputs from the same past transaction, it's a strong signal those are the real inputs (random decoy selection is unlikely to produce such a coincidence).

Status: inherent to rings. FCMP++ greatly weakens it (each input is "one of all"), but the number of inputs stays visible.

6. Transaction metadata

• Number of inputs and outputs: 1→2 is common, 15→1 stands out (consolidation).
• Fee: a non-standard fee reveals a non-standard wallet.
• Timing: transactions made right after receiving funds reveal the real input's age.
• tx_extra: non-standard fields, ordering, additional keys — a "wallet fingerprint".
• Unlock time: non-standard values stood out (removed in newer rules).

Status: FCMP++ barely touches this — it's the wallets' job: uniform behaviour, uniform formats.

7. Network layer

The node that first relayed a transaction is probably its author. Monero uses Dandelion++: a transaction first quietly passes along a chain of random nodes (the "stem") and only then is broadcast to everyone (the "fluff"). Plus Tor/I2P support. If you use someone else's remote node, it sees your IP and send time.

Status: off-chain, FCMP++ doesn't help. Use your own node or Tor.

Summary: what FCMP++ fixes

Next: how FCMP++ works.