Everything is open and transparent, so a "leak" is absolutely guaranteed. It appears the plan is to merely make some sort of change every 6 months such that an ASIC manufacturer hardly has time to develop a change, tape out, and actually mine for longer than a month or two. This should make it prohibitively expensive.
There are no "insiders" with Monero. Just like many FOSS projects, everything is developed in the open and entirely transparently. The first time anyone has visibility on PoW changes is when someone comes up with specifics and opens a PR, and as can be seen on the current PR there's little chance that the first pass is the one that will go in.
That's an unfair statement. The Monero Research Lab has several full-time PhD'd cryptographers who are paid for by crowdfunding from the community, just none who are specialised enough that they can comfortably sign off on the change. I think it's a good thing that those researchers don't overextend and act like they are all-knowledgeable.
But they DO need privacy, they're more at risk of targeted theft than regular users. ZCash fails at this by making it impossibly hard for an exchange to allow z-address withdrawals, and impossibly hard for a mobile app / hardware wallet to support them, which means large holders withdrawing from an exchange are painting a target on their back.
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).
> 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.
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'.
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-
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.
1. You're right, I would be surprised, because so many people have spoken out against ZCash - the compromises it makes are simply too great compared to the limited benefit over other solutions.
5. I've been using it since the Beta, and it's gotten progressively worse. I had high hopes for it at the beginning, but the result is a broken, poorly implemented scam, run by a team that hardly seem to understand how a cryptocurrency functions (e.g. https://github.com/zcash/zcash/issues/713)
By "the Monero guys" you mean the broader technical community that understand security software design?
Also, obscure origins are irrelevant when the technology is solid. Take the following examples: TrueCrypt, Bitcoin, MimbleWimble. Are you honestly arguing that TrueCrypt was bad?
1. Given that not even Zooko understands zk-SNARKs, the ZCash name is trademarked, and they've shut down their Reddit and IRC channels, there is no chance of a community of competent developers that understand the technology springing up. Also I wouldn't be proud of forking Bitcoin, especially when the changes that have been made are so substantial that they can't keep in sync with upstream.
2. No, it's not in my hands to do so. The onus is on ZCash to demonstrate this the way any other cryptography is proven: peer review, and time. ZeroCash has little of either.
3. Anyone that sees it as an advantage has no clue about disincentives or game theoretic attacks.
4. The exact point of failure is that they all booted off the same ISO that was provided by one person. Additionally, when an observer at one of the stations had their phone compromised they didn't shut the ceremony down and restart, they just continued. Also, the participants are just Zooko's buddies - who's to say they aren't conspiring together, and merely compromising the procedure for anyone who isn't part of that (e.g. Peter Todd)?
5. If privacy is not the default, and is immensely hard to use (due to the system requirements), it will hardly be used. The entropy of the private system will be restricted to a relative handful of users.
