[socrates1024]

This paper is an empirical analysis. The Monero reports introduced a theoretical attack with conditions, e.g. “a critical loss in untraceability across the whole network if parameters are poorly chosen and if an attacker owns a sufficient percentage of the network.” The news is that our research confirms, for the first time, that this is actually the case, and it affects actual transactions.

[ExactoKnight]

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?

[sgp_]

I wrote this unofficial response which I feel covers most items: https://1drv.ms/w/s!AjOt8D-0YjBHgYg_onISH13gCSfKng

[indolering]

> 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 potential mixins have already been spent."

[plasticmachine]

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

[dternyak]

> you will find that the primary technique they use for tracing 80% of transactions is found in the current version.

This is blatantly false, and I implore you to do further research before making and spreading such conclusions.

[axlprose]

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

I'm not thoroughly familiar with monero's internals, so someone please correct me if I'm wrong, but I thought it was well known that this was a deliberate design decision. Previously spent amounts don't actually run a risk of being double spent as they're only used anonymization purposes, as far as I understand. So why is this is considered "sloppy"?

[polarized]

It was a deliberate design decision as the issue was mitigated in a different manner starting in early 2016 (and introducing that check wouldn't be very effective anyway for other reasons).

The results of the mitigation are shown in the paper as Figure 5. The success of the techniques in the paper decline rapidly over the course of 2016 and would effectively reach zero if the dataset were extended (this is noted in the text when it states that RingCT transactions are immune, although even without RingCT it would still effectively reach zero)

[polarized]

The technique in the second half of the paper is not able to trace any transactions at all, as I explained in more detail in another reply. It identifies a partial weakness in the ring signatures but it is not capable of breaking them.