What privacy issues did Monero have and still has?

Question

Has there been any scientific research regarding the promised privacy and security of Monero?

Have there been attacks on the Monero network in the past? If so, what has been done to combat those?

Are there currently any risks for my privacy when using Monero? Is blockchain analysis possible and will this change in the future?

Answer 1

The Monero Research Lab is a team of voluntary researchers, scientists and academics that did analyse Monero and its predecessor CryptoNote in the past, explaining both past attacks and possible privacy issues in the current network. Their research is mostly funded by donations from the Monero community and is publicly available.

In the following segment I will list every security issue they found and their implemented or proposed solution. Elaborations are my comments but are mostly based on the research results.

TL;DR

• Seven possible attack vectors
• Six solutions have been implemented
• One issue is not yet resolved

---

MRL-0001: A Note on Chain Reactions in Traceability in CryptoNote 2.0

If an attacker owns many transactions and you use solely his outputs as mixins, he is able to deobfuscate the ring signature. He could spam the network with transactions to increase the probability of becoming a mixin.

Solution: Enforced minimum mixin of 2 will reduce the share of evil outputs over time

Status: Implemented

Elaboration

• Fees and a possible deflation make this attack rather expensive for the excessive amounts the attacker would need to buy, hold and move: "If Burns controls half of all outputs, then 12.5% of all new transactions will have a ring signature composed entirely of his outputs"
• Accidental deobfuscations (mixin = 0) can be prevented by enforcing a protocol level minimum mixin
• With a protocol level minimum mixin of 2 and the resulting 12.5% chance of deobfuscating a transaction, the share of the malicious outputs gets reduced with every new transaction on the network, effectively "repairing" itself as long as the attacker does not keep on producing outputs

MRL-0002: Counterfeiting via Merkle Tree Exploits within Virtual Currencies Employing the CryptoNote Protocol

On 4 September 2014, an unusual and novel attack was executed against the Monero cryptocurrency network. This attack partitioned the network into two distinct subsets which refused to accept the legitimacy of the other subset.

Solution

On [...] the same date as the attack, the first solution to the exploit was publicly announced by Rafal Freeman [...] The Monero development team released patch 0.8.8.3 on 6 September 2014 to [...] allow miners to identify the A side of the network [...] and to identify foreign nodes with the B-side version of block 202612

Status: Implemented

Elaboration

• A bug in the fresh fork of the poorly documented Bytecoin implementation caused this issue that was fixed temporarily on the same day and permanently two days later
• The attack made different nodes not recognize each other as correctly working, splitting the nodes temporarily into two parallel blockchains and effectively doubling the amount of funds per person

MRL-0004: Improving Obfuscation in the CryptoNote Protocol

One may have reasonably assumed that the original CryptoNote developers would have implemented a standardized denomination requirement for all transaction outputs, but [...] the protocol does not disallow any strange denominations [...] Hence, no mix-ins are possible

Solution: RingCT hides the amounts of transactions, making denominations useless and removing dust

Status: Implemented

---

An observer cannot distinguish which transaction output [...] is the output actually being spent [...] However, [...] an attacker may model the cumulative probability that the output has already been spent as an increasing function of time [...] Hence, [...] the youngest output used to fashion the ring signature is the most likely output to be the genuine output being spent

Solution: No solution in sight ( discussion for a solution can be found here )

Elaboration

When an exchange rate is experiencing a [...] inflation, rational users are more likely to spend their transaction outputs [...] When an exchange rate is experiencing a [...] deflation, rational users are more likely to hoard [...] Hence, the distribution of transaction output ages will at least vary over time, and, presuming any proportion of users are rational will certainly depend sensitively on the economic performance of the currency. It is unwise to design security recommendations around the economic performance of our protocol.

Note: This issue is currently the biggest issue of Monero privacy and was subject to another scientific paper, which can be found here. This research is under criticism for not clarifying the ties to the ZCash Foundation well enough.

---

an observer may conclude that the outputs stemming from a common root transaction are more likely to belong to the true signer of the transaction

Solution: RingCT will prevent denominations and therefore reduce the probability of outputs stemming from the same transaction

Status: Implemented

if a set of distinct transactions has some common data (such as a common block height) and if all transactions in this set use mix-ins with some other common data, then it is likely that these transactions are related by a common user

Solution: RingCT reduces the amount of shared data

Status: Implemented

MRL-005: Ring Confidential Transactions

One possible attack against the original CryptoNote or ring-coin protocol is blockchain analysis based on the amounts sent in a given transaction

it requires a given [...] ring signature with other pubkeys having the same amount. For less common amounts, this means there may be a smaller number of potential pairs

Solution: RingCT. MRL-0005 is actually all about how it works.

Status: Implemented

Answer 2

This is not a protocol level issue, but a network one: someone monitoring the network can still connect transactions and the IP addresses of the nodes that first broadcasted them; and if you just run Monero's client out of the box there is no built-in protection against that!

Possible solutions

1. Run your full node through TORSOCKS following the instructions here. This is the only solution available right now.
2. Wait for I2P integration, which is considered a better solution by some Monero devs who are currently working on integrating it to Monero's core client.
3. Implementing a client level broadcasting system that obscures the origin of the transactions by using onion routing or the dining cryptographers protocol, as I suggested before here.

Also, from this reddit post:

Each daemon has a node ID stored in the p2pstate.bin file. If you switch between Tor and clearnet, this node ID can be used to link an IP address with your Tor session.

To avoid this issue either:

1. Always run over Tor, never over clearnet (not even one time); or
2. When switching between Tor and clearnet (in either direction), delete the p2pstate file, which can be found in the .bitmonero folder. This will generate a brand new random node ID next time the daemon is started.