Update 2017-04-19-an-unofficial-response-to-an-empirical-analysis-of-linkability.md

Check this please. I think it is ready for release now.

_posts/2017-04-19-an-unofficial-response-to-an-empirical-analysis-of-linkability.md

@@ -16,19 +16,19 @@ The Monero contributors and community at large always appreciate any research do
 
 The Monero contributors appreciate the effort that has gone into this mentioned publication and research methods. It helps quantify several realizations that had already been known to the Monero community at large for a long time (ref: [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf) and [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf)), including the following:
 
-1.  0-mixin transactions (those that only include the real input and no others) are traceable on the blockchain. [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf) (published September 2014) also points this out, and Monero reacted to the concern by prohibiting 0-mixin transactions from the network in April 2016. The current minimum mixin allowed on the network is 2, which was mandated in March 2016. In September 2017, the minimum will be increased to at least 4, though there is [some discussion](https://github.com/monero-project/monero/issues/1673) going on in the community to choose the exact value. For clarification of terms used, ringsize is a newly-adopted term to replace mixin to remove comparisons to traditional mixing services. Ringsize = mixin + 1.
+1.  0-mixin transactions (those that only include the real input and no others) are traceable on the blockchain. [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf) (published September 2014) also points this out, and Monero reacted to the concern by prohibiting 0-mixin transactions from the network in April 2016. The current minimum mixin allowed on the network is 2, which was mandated in March 2016. In September 2017, the minimum will be increased to at least 4, though there is [some discussion](https://github.com/monero-project/monero/issues/1673) going on in the community to choose the exact value. For clarification of terms used, ringsize is a newly-adopted term to replace mixin with the intentions of removing comparisons to traditional mixing services. Ringsize = mixin + 1.
 
-2.  The prohibition of 0-mixin transactions has allowed the network to recover relatively quickly by making it harder to know which input is used. This paper helps quantify this recovery (see appendix).
+2.  The prohibition of 0-mixin transactions has allowed the network to recover relatively quickly by making it harder to know which input is used. This paper helps quantify this recovery, from about 95% traceable to 20% traceable (see appendix).
 
-3.  The proportion of transaction inputs that are deductible has fallen substantially from 1 January 2016 to 1 Feb 2017 with 2 and 4 mixin transactions. Respectively, these fell from 82% and 72% to 41% and 23% (see appendix).
+3.  The proportion of transactions that have their inputs deductible has fallen substantially from 1 January 2016 to 1 Feb 2017 with 2 and 4 mixin transactions. Respectively, these fell from 82% and 72% to 41% and 23% (see appendix). Furthermore, this proportion is down to 0% with RingCT transactions, which are now [over 99% of all new transactions on the network](http://moneroblocks.info/stats).
 
-4.  The phenomenon where the most recent input is the real one is a concern when using Monero. There is no way to prove that this input is indeed the correct one, and with recent transactions, the assertion is nearly impossible to prove and is accurate less than half of the time. As the report states, there is about a 40% chance that the first input in a default transaction is the real one. Ideally, this number should be closer to 20% (1 in 5). Note that this does not mean that there is a 40% chance that this transaction is traceable (see appendix).
+4.  The phenomenon where the most recent input is the real one is a concern when using Monero. There is no way to prove that this input is indeed the correct one, and with recent transactions, the assertion is nearly impossible to prove and is accurate less than half of the time. As the report states, there is about a 40% chance that the most recent input in a default transaction is the real one. Ideally, this number should be closer to 20% (1 in 5). Note that this does not mean that there is a 40% chance that this transaction is traceable (see appendix). Increasing the transaction ringsize has only a marginal improvement.
 
 ## RECOMMENDATIONS AND RESPONSES
 
 The following are the recommendations listed in the paper and responses to them:
 
-1.  The mixing sampling distribution should be modified to closer match the real distribution. We agree with this recommendation. The discussion covering the possible ways to do this, along with all associated research, [can be seen on GitHub](https://github.com/monero-project/monero/issues/1673) . As the paper acknowledges, we made a temporary improvement to the selection algorithm to choose more recent inputs (instead of pure random selection) in December 2016. Further improvements are required, and they are planned to be ready before or at the September 2017 hardfork date.
+1.  The mixing sampling distribution should be modified to closer match the real distribution. We agree with this recommendation. The discussion covering the possible ways to do this, along with all associated research, [can be seen on GitHub](https://github.com/monero-project/monero/issues/1673) . As the paper acknowledges, we made a temporary improvement to the selection algorithm to choose more recent inputs (instead of pure random selection) in December 2016. Further improvements are required, and they are planned to be ready before or at the September 2017 hardfork date. As the paper notes, this change is not consensus-critical. It can be done the day after completion without a hardfork.
 
 2.  The Monero community should engage in further data-backed analysis of privacy claims. We agree with this recommendation. Data-backed claims are an excellent way to improve the Monero privacy and security features. As stated in the paper, the threats discussed in the paper were discussed in the community previously. Unlike the paper claims, these discussions were not “informal”; instead, they were published in our [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf) research paper in January 2015. Nevertheless, several of these attack vectors explained in the Decentralized Systems Lab paper are quantified for the first time.
 
@@ -38,19 +38,17 @@ The following are the recommendations listed in the paper and responses to them:
 
 The Monero community would like to list several concerns with this research paper. They are documented below:
 
-1.  We believe that a large proportion of 0-mixin transactions are pool payouts. These transactions should come to no one’s surprise that they are traceable, since the pools themselves publish the payment amount to each transaction hash. Thus, we believe that the claims stemming from the traceability of transactions before 0-mixin transactions were banned to be misplaced. If, for example, 50% of non-pool payouts used a positive mixin and 0% of pool payouts did, then the traceability is less for the transactions that use these mixins and greater for pool payouts. We recommend that this is acknowledged in a later iteration of the paper. Ideally, the proportion of pool payouts can be found and compared to the proportion of non-pool payouts, with different traceability proportions for each. We acknowledge that these pools using 0-mixin transactions undermines the non-pool payout transactions, though these non-pool transactions would be better shielded than if they were using 0-mixins themselves. Furthermore, all transactions are still unlinkable by the MRL definition of the word (see "Other Information" point 4) ([source](https://www.reddit.com/r/Monero/comments/65dj7u/an_empirical_analysis_of_linkability_in_the/dga1rza/?context=1)).
+1.  We believe that a large proportion of 0-mixin transactions are pool payouts. These transactions should come to no one’s surprise that they are traceable, since the pools themselves publish the payment amount to each transaction hash. Thus, we believe that the claims stemming from the traceability of transactions before 0-mixin transactions were banned to be misplaced. If, for example, 50% of non-pool payouts used a positive mixin and 0% of pool payouts did, then the traceability is less for the transactions that use these mixins and greater for pool payouts. We recommend that this is acknowledged in a later iteration of the paper. Ideally, the proportion of pool payouts can be found and compared to the proportion of non-pool payouts, with different traceability proportions for each. There are several reasons why these transactions neither reduce the anonymity of the transaction itself or other users. In regards to the former, coinbase transactions (ie: new rewards given to the pool) are 0-mixin, since having mixins is useless if the input is brand new and seen for the first time. Anyone who mines understands that the source of thier money is clear. In regards to other transactions, the pool payouts occur within the day, reducing the negative impact spending these transactions has on other users who may have borrowed the input for their transaction. Thus, pool payouts should include additional mixins, but excluding them has relatively minimal harm. The larger threat is the opportunity cost, where the additional mixins could provide greater levels of privacy for other users. Furthermore, all transactions are still unlinkable by the MRL definition of the word (see "Other Information" point 4) ([source](https://www.reddit.com/r/Monero/comments/65dj7u/an_empirical_analysis_of_linkability_in_the/dga1rza/?context=1)).
 
 2.  We think further emphasis should have been placed in the paper to explain that the claims are only minimally applicable with the state of Monero transactions since March 2016, with the relevance decreasing over time. Though it is mentioned that their first analysis method has little if any current or future relevance, the claims still include these transactions. Furthermore, the report incorrectly states that most transactions in 2016 are traceable with the 0-mixin method. This is largely untrue, since these were prohibited in March, and most transaction volume for the year occurred during and after August. Nevertheless, many of these post-March transactions have inputs that can be deducible, but the traceability typically is not as severe as with 0-mixin transactions. The transactions that are most vulnerable are those in 2014 and 2015.
 
 3.  Under the “ethics” section, they state that the paper was published immediately before countermeasures could be deployed. While this is understandable from the given perspective that the blockchain history is not going away anytime soon (or ever), we wish that they had given us an advance copy of the finished draft so that we could have discussed our concerns with the report itself. We wish not to censor any of the research (instead, we encourage research!); however, we hope that future care can be taken before the release of misleading assertions.
 
-4.  Andrew Miller was named in the paper as a consultant to the Zerocoin Electric Coin Company and a board member of the Zcash Foundation. Zcash is a cryptocurrency with a focus on privacy that uses different technology than Monero. However, [he downplayed his involvement in an interview](https://cointelegraph.com/news/monero-transactions-history-can-be-revealed-and-exposed-research) he later participated in about this paper. We feel author involvement in cryptocurrencies with similar interests should be fully disclosed, though he did refer people to the first page of the report. Nevertheless, we feel this is extremely poor form.
-
-5. The deducibility claims are clearly misleading. The report shows a proportion of transactions where at least one input is deducible. However, for all transactions since March 2016, all transations include at least 2 other inputs. Thus, if one of these inputs is deducible, it is still not traceable. Sure, the feature is not working as well as intended. In an example transaction with a mixin of 9 where 5 of the inputs are deducible, the transaction is still sourced from 1 of 5 plausible options, instead of 1 in 10. Nevertheless, the claims this paper makes, such that including all transactions that have at least one deducible transaction as traceable, are completely wrong. We suggest that the paper also considers making figure 1 much clearer to say that it shows the proportion of transactions where one or more inpiuts are deducible, as well as providing a new table that shows the transactions where all of the inputs are deducible. Only in a case where all the inputs are deducible should the transaction be considered "traceable".
+4.  Andrew Miller was named in the paper as a consultant to the Zerocoin Electric Coin Company and a board member of the Zcash Foundation. Zcash is a cryptocurrency with a focus on privacy that uses different technology than Monero. However, [he downplayed his involvement in an interview](https://cointelegraph.com/news/monero-transactions-history-can-be-revealed-and-exposed-research) about this paper. We feel author involvement in cryptocurrencies with similar interests should be fully disclosed, though he did refer people to the first page of the report. Nevertheless, we feel this is extremely poor form.
 
 ## OTHER INFORMATION
 
-1.  The timing of the publication. This paper was released approximately an hour before the hardfork. While it is impossible to know the reason for the specific timing without an admission, we speculate that this was timed to draw as much attention to the paper as possible. More people would have been tuning in to see how the hardfork was proceeding than typical community participation traffic. Andrew Miller has responded to this criticism in a Reddit PM to the author, saying "the timing of our release with the imminent hard fork was totally unintentional and a coincidence. No one on the team noticed there was a hardfork planned, and we'd definitely have delayed till afterward if we had."
+1.  The timing of the publication. This paper was released approximately an hour before the hardfork. While it is impossible to know the reason for the specific timing without an admission, we speculate that this was timed to draw as much attention to the paper as possible. More people would have been tuning in to see how the hardfork was proceeding than typical community participation traffic. Andrew Miller has responded to this criticism in a Reddit comment, saying "the timing of our release with the imminent hard fork was totally unintentional and a coincidence. No one on the team noticed there was a hardfork planned, and we'd definitely have delayed till afterward if we had."
 
 2.  This paper was shared as “new research” about Monero. While the research is itself new and some of the analysis is the first time that some concerns have been quantified, these concerns themselves are not new. In sharing the paper, the authors often posted misleading claims that asserted these concerns were new.
 
@@ -76,15 +74,13 @@ We appreciate the effort that went into this research paper, but we suggest the
 
 6.  Consider cooperating with Riccardo Spagni to permanently include the research portion of this paper in our Monero Research Lab documents.
 
-7. Make clear that when certain (but not all) inputs can be deduced, that this does not make the transaction traceable. For instance, if 5 of 10 inputs for a mixin 9 transaction can be deduced, this is still not a traceable transaction.
-
 ## APPENDIX
 
 **Figure 5 from the report showing the fraction of deductible outputs. Notice the large drops following block height 1,000,000, when 0-mixin transactions were prohibited. Furthermore, these outputs likely do not include all those used in a singe transaction. For instance, for a mixin 9 transaction, 5 may be deduced. This means that the transaction would be reported here as deducible, even though it is not traceable.**
 
 <img src="/blog/assets/linkability-response/figure5.jpg" style="width: 600px;"/>
 
-**Table 2 from the report showing the proportion of transactions with a positive mixin that can be deduced. We would like to point out that for temporal analysis, the input can be guessed with this probability, but there is no level of certainty following March 2016 (shortly after the 0.9.0 release).**
+**Table 2 from the report showing the proportion of transactions with a positive mixin that can be deduced. We want to make clear that the findings of this chart and analysis method have absoutely zero relevance to RingCT transactions.**
 
 <img src="/blog/assets/linkability-response/table2.jpg" style="width: 800px;"/>
 
@@ -92,6 +88,16 @@ We appreciate the effort that went into this research paper, but we suggest the
 
 <img src="/blog/assets/linkability-response/table3.jpg" style="width: 800px;"/>
 
-**Tweet from research contributor with wording that we feel is misleading**
+**Examples of statements we find misleading**
+
+This is a tweet from a contributor to the paper.
 
 <img src="/blog/assets/linkability-response/tweet.jpg" style="width: 600px;"/>
+
+This image is from the [CoinTelegraph interview](https://cointelegraph.com/news/monero-transactions-history-can-be-revealed-and-exposed-research). Based on the wording, you may think an attacker could determine with certainty which input is yours. However, in reality, the attacker can guess and be correct less than half of the time. Furthermore, even if the attacker guesses correctly, there is no way of proving this with certainty with data from the blockchain alone.
+
+<img src="/blog/asstes/linability-response/cointelegraph.jpg" style="width: 600px;"/>
+
+Andrew Miller asked us to include other statements from the researchers or Zcash Foundation members that we feel is misleading. This paper is not supposed to be a comprehensive list of such statements. It is only really useful in providing a few examples.
+
+This draft was shown to Andrew Miller before release on the website. Some of his considerations have been included in this response.