On-chain tracking of Monero and other Cryptonotes
Final nail in the coffin of Monero privacy
In the previous articles we discussed how to turn churning into incriminating evidence using external metadata [ 1 ] and how lack of churning will let your funds be tracked through simple output tagging (Knacc attack)[ 2 ]. In this article we will discuss how to track churning — and do active tracking attacks on-chain without help of any metadata. In fact you can do it on Monero blockchain right now, without anyone being any wiser.
Simple output merging attack
This attack builds upon the “Heuristic II” attack (section 5.2) from A Traceability Analysis of Monero’s Blockchain by Amrit Kumar, Clément Fischer, Shruti Tople, and Prateek Saxena. IACR Cryptology ePrint Archive, 2017. [ link ]
In this attack the authors introduce a very simple and intuitive concept. If a transaction spends both outputs of another transaction then it is overwhelmingly likely that those are the real outputs. An observant reader here will notice that additionally it identifies those outputs as belonging to a single entity — even if the actual private keys were different.
Both those observations will become important as we move on to show how to both track churning and deanonymise further transactions using this method.
Normal transaction flow
This diagram shows normal transaction flow. Here Alice has four outputs 1A-1D. She spends 1C and 1D in T1 on something. She receives 2A as change in her wallet. T2 spends that change and 1B, generating another change output 3A, and so on.
Last week I explained how Knacc attack enables tracking users. Standard Monero advice is to “churn” (send money to yourself). I warned users very strongly not to do it. Author of the attack disagreed, possibly unaware of this possibility [ 1 ]. Let’s see how such churn looks in context.
Here Alice had three outputs in her wallet (1A, 1B and 1C). She used 1B and 1C to send some money to herself in T1, then paid some people in T2 and T3.
You can immediately see that unlike in normal transaction flow, 3A, 2A and 2B form a ring. When we see that in possible inputs in ring signature group we can discard all other options as it is very likely that those are the real outputs.
What’s the chance of this happening by accident? Negligible — I already covered the calculation in Knacc attack article. For ring size of 3 (three generations on a graph) the probability is exactly the same, even larger ring sizes are likely traceable with high degree of certainty using nothing more than a simple blockchain scan.
Active tracking attack
Did you notice how we deanonymised T2? We know that T2 was created by Alice, we know that 3A is change, and the other output didn’t form another ring therefore Alice either hasn’t spent it yet or sent it to someone else.
How about if instead of waiting for Alice to churn, we send her a transaction like T1. Her wallet will be smart enough to select those outputs for different transactions, but they will still form a detectable ring like above.
In fact T1 does not have to be a single transaction at all in this scenario. All we need is multiple payments into Alice’s wallet to start creating rings and deanonymising her spending. Let’s go back to the normal flow diagram and assume that Bob sent outputs 1A and 1D. Since there is a ring between then, Bob now knows T1, T2 and T3 were all generated by Alice.
I would like to thank Dash and ZCash community for helping me spread awareness of privacy issues after I have been banned from @monero Telegram channel [ 3 ].