Live data from Hacker News

80% of Monero Transactions Trivially De-Anonymized

ipfs.io

71–80 of 88 posts

Re: 80% of Monero Transactions Trivially De-Anonymized

#71
post #19

Earlier quoted context omitted.

> Are you talking about the fact that Zcash has, as a feature, the ability to make non-anonymous payments as well? Last I checked virtually none of Zcash's transaction used the anonymous payment feature (presumably because the performance of it is very poor). So it's plausible that monero transactions could practically end up with a larger anonymity set in absolute terms than zcash (especially for current monero, whi…

There is nothing preventing memory usage from being brought into the ~250MB range. The performance issues stem from a legacy codebase built by academics and a focus on safety and enterprise features. >So it's plausible that monero transactions could practically end up with a larger anonymity set in absolute terms than zcash (especially for current monero, which has CT and a minimum mixin size). No, it isn't. There wi…

To correct a minor point, none of the current Zcash code comes from the Zerocash academic prototype. All of the code that had come from the prototype was rewritten before launch (mainly in https://github.com/zcash/zcash/pull/625 ).

Much of the performance issue comes from a single design decision made in Zerocash: to use SHA-256 for the Merkle tree, PRF, and note commitment hashes. We'll be changing this for the Sapling update.

-- Daira Hopwood (Zcash developer)

Re: 80% of Monero Transactions Trivially De-Anonymized

#72

Earlier quoted context omitted.

There is nothing preventing memory usage from being brought into the ~250MB range. The performance issues stem from a legacy codebase built by academics and a focus on safety and enterprise features. >So it's plausible that monero transactions could practically end up with a larger anonymity set in absolute terms than zcash (especially for current monero, which has CT and a minimum mixin size). No, it isn't. There wi…

To correct a minor point, none of the current Zcash code comes from the Zerocash academic prototype. All of the code that had come from the prototype was rewritten before launch (mainly in https://github.com/zcash/zcash/pull/625 ). Much of the performance issue comes from a single design decision made in Zerocash: to use SHA-256 for the Merkle tree, PRF, and note commitment hashes. We'll be changing this for the Sapl…

My apologies, I had assumed the codebase was legacy due to some lamentations about not being able to use Rust.

I hope my portrayal of the performance issues was appropriate.

Re: 80% of Monero Transactions Trivially De-Anonymized

#73
post #6

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.

> 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? I…

What do you mean "if Monero fixes everything"? They already fixed everything, which is why the paper shows the decline in their ability to deduce things, and the paper COMPLETELY STOPS showing data after RingCT went into action.

Perhaps you should familiarise yourself with the papers that Monero themselves published on this in September 2014, and the follow-up in January 2015? Here-

https://lab.getmonero.org/pubs/MRL-0001.pdf

https://lab.getmonero.org/pubs/MRL-0004.pdf

Now the recommendations made in that 2nd paper were only instituted in the v2 hard fork in March 2016, because hard forks are hard and it was their first one, but it doesn't change the fact that they published two papers on it to warn the community, made immediate changes so that updated clients used minimum ring sig sizes, and then hard forked to ban mixin 0. Publishing a paper on an already-discovered and already-solved issue two years later isn't particularly interesting or novel.

Re: 80% of Monero Transactions Trivially De-Anonymized

#74
post #5

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 reddi…

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'.

> I haven't seen any evidence of 'academic dishonesty'.

How about one of the authors Tweeting out that 80% of the Monero transactions have been deanonymized (https://twitter.com/random_walker/status/852918816455655425), a claim that is neither true nor remotely correct?

This paper is akin to me publishing a paper noting how insecure Windows for Workgroups 3.11 is, providing advice for securing it, and then Tweeting out that that the paper found that "Windows is trivially insecure out the box". Sure, the paper would technically be correct, and my Tweet might even technically be correct, but it would be irrelevant since nobody uses Windows for Workgroups 3.11.

Nobody CAN use mixin-0 transactions in Monero, because they've been banned since a March 2016 hard fork that took over a year for them to plan and roll out. Nobody can be affected by down-chain use of those mixin-0 transactions because RingCT doesn't allow you to create ring sigs form them, which was added in the December 2016 hard fork.

It's no wonder, then, that the paper, and accompanying website, only go up to the end of 2016 - they have no valid data from the beginning of 2017 onwards, and have published the paper seemingly only as a 'hit piece'.

Re: 80% of Monero Transactions Trivially De-Anonymized

#75

Earlier quoted context omitted.

The core of this paper's claim seems to be that 0-mixin transactions leave user's exposed, however Monero has since prohibited these types of transactions. So yes, these types of transactions going backwards are exposed, but moving forward they will not be. This appears to be the Monero's team main response. Am I missing any other substantive arguments from the paper?

> Am I missing any other substantive arguments from the paper? The second half of the paper, "Linking with temporal analysis". If you read the second half of the introduction, you will find that the primary technique they use for tracing 80% of transactions is found in the current version. The sloppiness of this code is really shocking, "when the Monero client chooses mixins, it does not take into account whether the…

> The sloppiness of this code is really shocking, "when the Monero client chooses mixins, it does not take into account whether the potential mixins have already been spent."

That's because RingCT removed the ability to create a ring signature with those outputs, so adding a complex whitelist / blacklist mechanism would have been a massive waste of time.

Re: 80% of Monero Transactions Trivially De-Anonymized

#76
post #5

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 reddi…

While they quantify the impact of an older vulnerability, the 80% figure comes from clients who are using the current implementation.

I doubt it; they stop serving data after the beginning of 2017 precisely because RingCT breaks their algorithms.

Re: 80% of Monero Transactions Trivially De-Anonymized

#77

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 pa…

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

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).

Re: 80% of Monero Transactions Trivially De-Anonymized

#78
post #29

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…

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.

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-0004.pdf

Re: 80% of Monero Transactions Trivially De-Anonymized

#79

Earlier quoted context omitted.

> The point they are trying to make is that the anonymity set between shielded addresses is that of all transactions in the anonymous set. This way of stating is somewhat questionable in light of the claims in the second half of the paper. What is shown in the second half of the paper is that all possible sources are not equally likely and this most probably applies to Zcash (and every other coin) as well. In the Fig…

You're mistaken in saying that it is most likely that the actual note is the most recent one for Zcash. The figure gives a slightly misleading impression because it has to show few enough inputs to fit on the page. The number of possible inputs is the total number of previous shielded notes (before the JoinSplit anchor) that the adversary does not control or know to have been spent. There have been around 129000 Join…

Yes you are likely correct that "most recent" being the "most likely" is not accurate. However, there is a distribution and it has a peak. It is certainly not flat, so it is incorrect to say that the entire set constitutes an "effective anonymity set" while at the same time claiming that Monero's ring signatures only have an "effective mixin size" that is smaller than the actual size due to the same non-uniform distribution.

> In Monero, the adversary can refine their guess of the distribution based on the inputs that are actually mixed in, and that is what creates the privacy weakness.

That is not what is claimed in Section 4 of the paper. Section 4 merely indicates that of potential outputs, the time distribution introduces a bias toward the most recent (actually in Monero this might be inaccurate in some cases too: very, very recent might be less likely than merely very recent; the paper does not examine this). In Zerocash the same time distribution bias exists, though across a larger set of potential coins (or notes or whatever it is you call it).

However, very old members of that set are essentially irrelevant as their probability in the distribution is almost certainly extremely low (this is the same reason that more older outputs in Monero are essentially irrelevant).

Re: 80% of Monero Transactions Trivially De-Anonymized

#80
post #30

Earlier quoted context omitted.

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

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.

> Neither of these weaknesses is entirely new, having been discussed (but not addressed) by Monero developers since as early as 2015. Our work provides the first quantitative assessment of the severity of these weaknesses.
Post reply on HN