Merge pull request #722 from SamsungGalaxyPlayer/patch-2

Update links to MRL-0004

_posts/2018-03-29-response-to-an-empirical-analysis-of-traceability.md

@@ -42,7 +42,7 @@ This research paper includes several findings, some of which are completely new,
 
 11. The paper lists several known illicit uses of Monero and the steps that law enforcement and attackers can use to potentially learn more about these Monero transactions. The Monero project condemns illicit use of Monero.
 
-12. The paper ends with three recommendations: 1) updating the decoy sampling distribution, 2) avoiding publicly deanonymized outputs as decoys (eg: public pool payouts), and 3) warning users their transactions before RingCT are vulnerable to tracing analysis. The first two are forward-looking recommendations for improving the protocol. The Monero project agrees with both of these forward-looking recommendations. The Monero project stands by its statement that it has always been transparent about Monero's limitations and suggested improvements. The privacy-enhancing recommendations discussed in [MRL-0004](https://lab.getmonero.org/pubs/MRL-0001.pdf), publicly published in January 2015 (over 2 years before the first version of the Malte Möser, et al. paper) were not fully-implemented until September 2017. In fact, the exact same limitations of zero-decoy transactions were discussed in [MRL-0004](https://lab.getmonero.org/pubs/MRL-0001.pdf). Below is a relevant quote from [MRL-0004](https://lab.getmonero.org/pubs/MRL-0001.pdf) which covers the same major attack as in the Malte Möser, et al. paper:
+12. The paper ends with three recommendations: 1) updating the decoy sampling distribution, 2) avoiding publicly deanonymized outputs as decoys (eg: public pool payouts), and 3) warning users their transactions before RingCT are vulnerable to tracing analysis. The first two are forward-looking recommendations for improving the protocol. The Monero project agrees with both of these forward-looking recommendations. The Monero project stands by its statement that it has always been transparent about Monero's limitations and suggested improvements. The privacy-enhancing recommendations discussed in [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf), publicly published in January 2015 (over 2 years before the first version of the Malte Möser, et al. paper) were not fully-implemented until September 2017. In fact, the exact same limitations of zero-decoy transactions were discussed in [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf). Below is a relevant quote from [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf) which covers the same major attack as in the Malte Möser, et al. paper:
     
 > To see an example of this, say that Alice fashions a ring signature using the mixins {Bob, Cynthia, Doug}. For any observer, then, the list of possible senders of the transaction is clearly {Alice, Bob, Cynthia, Doug}. If Bob, Cynthia, and Doug then each spend their transaction outputs with zero mix-ins, then it is obvious [to] any observer that they no longer own those transaction outputs. Hence, they can be excluded from the list of possible senders of Alice’s transaction, and Alice is now exposed as the sender of her transaction. It is not as if only three users, Bob, Cynthia, and Doug, spent their transactions in the clear, but as if all four users spent their transactions in the clear. Hence, any signatures using Alice’s transactions as a mix-in are now also compromised. If enough transactions are affected, there can be second-order effects, leading to a chain reaction.
 
@@ -52,7 +52,7 @@ The Monero project has the following recommendations for the research paper:
     
 1. We recommend the authors update the wording regarding the selection algorithm used between January 2017 and September 2017 to be defined as such, not as the current selection algorithm. The Monero project highly encourages the authors to test the [current selection algorithm](https://github.com/monero-project/monero/pull/1996), which was implemented specifically to address concerns in the first version of the paper. Furthermore, we recommend adding information saying the selection algorithm was modified in the applicable update section in September 2017, after version 0.11.0.
 
-2. We recommend that the authors acknowledge the earlier expression of zero-decoy transactions as a concern, and that the risk was accurately described (though not as thoroughly quantified) in [MRL-0004](https://lab.getmonero.org/pubs/MRL-0001.pdf), published in January 2015. While we agree that certain additional communications can be made, we encourage the authors to focus on this being a previous (since patched) vulnerability that was publicly documented for several years prior. The Monero project feels that it has diligently made this information available to the public under a resources section of its website.
+2. We recommend that the authors acknowledge the earlier expression of zero-decoy transactions as a concern, and that the risk was accurately described (though not as thoroughly quantified) in [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf), published in January 2015. While we agree that certain additional communications can be made, we encourage the authors to focus on this being a previous (since patched) vulnerability that was publicly documented for several years prior. The Monero project feels that it has diligently made this information available to the public under a resources section of its website.
 
 ### Further Research