[...8<...]
The relevant (to your stated concern) distinction from Zerocash (and a friendly reminder to not conflate Zerocoin with Zerocash because the former requires equal revealed values and doesn't integrate with hiding values) is that there isn't a global trusted master key (generated once at setup of the sytem) to be potentially abused (if the trusted setup was gamed some how). Yet in both systems, if you can muster enough computing resources even just once (and/or break/weaken the number-theoretic cryptographic assumptions security), you can create unlimited money out-of-thin-air and this can't be detected (unless detection means everyone has the same level of breakage capability and all values can be globally unmasked rendering value hiding useless).
Homomorphic values and ring signatures come with potentially huge anti-DDoS costs as I have been explaining in a thread I started in the Bitcoin Discussion forum. In that thread, I have alluded to we might be better off to just eliminate homomorphic (hiding) values and also eliminate Cryptonote's one-time ring signatures and move to something like CoinShuffle, because we are going to need to do a CoinShuffle any way. The details on this tradeoff need to be further mulled over and elucidated.
[...8<...]
Anonymity is very difficult to accomplish holistically especially at-scale (Monero is no where near accomplishing that at-scale) and it doesn't come for free.
A generative essence realization is there is no possible way to obfuscate your IP address with an autonomous cryptographic protocol (such as RIngCT or Cryptonote). The only way to obfuscate IP addresses is with an interactive mixnet, which then either incurs a simultaneity requirement or the mixnet must generalize to many forms of internet traffic so a sufficient mix set always available. But especially generalized mixnets suffer from Sybil attacks because of the cost of scaling relaying nodes scales with traffic and DDoS. As smooth knows from our past private discussions (afair last year), my only idea on how to attack the Sybil problem of Tor and I2P is to pay the nodes you are want to relay through for an onion routing. But this comes with another set of holistic issues. So far, I haven't been able to design the system that is immune to the NSA. I am still working on this problem, but have deprioritized it, because to my consternation it is such an intractable quagmire (a.k.a. clusterfuck).
[...8<...]
Well that is the sort of statistical pattern that I think it implausible to hide if the person who needs to know thus can afford the resources to know.
I don't think in this Technocracy age of Big Data, one can't hope to obscure patterns on large data sets. The generative essence of the implausibility is that the statistical patterns hidden at one layer, leak into the next layer, so it becomes a requirement for a globally leak-proof synergy of activity in cyberspace. It seems futile from that high-level perspective. And I stubbornly didn't want to accept that, but having really looked deeply at the technical issues, I now lean to that being the hard reality.
That is why I posit that the paradigm of wealth stored in forms that others can easily emulate, tax, and expropriate is dying.
[...8<...]
Zerocash does hide your identity on the block chain even if your IP address is correlated across multiple transactions that you send to the block chain, because in Zerocash the payer(s) and payee(s) are obscured and proven in a non-interactive zero knowledge proof (NIZKP). This is accomplished by proving that the machine ran a certain program (and no other program) on the inputs and that result was "true" (i.e. verified), rather than proving something algebraically about the variables to the program. This computational witness requires the global master key setup.
Whereas, Cryptonote one-time rings mix the payer amongst a group of payers with the requirement that it is publicly verifiable that each payer can only be spent one-time. The one-time key is manufactured by the Diffie-Hellman (ECDH) like exchange that creates a new stealth payee address on each spend and that stealth address can only be spent once. So the problem is that if your IP address is correlated across spends, it becomes possible to link stealth addresses together as the same payee and then start to unmask the anonymity set of the payer rings.
So it would seem that Zerocash is the solution, except read my discussion at the quoted link about anti-DDoS protection. The problem is the huge verification cost for each Zerocash transaction and thus giving the attacker a huge asymmetric advantage when sending invalid transactions, i.e. unprotected Zerocash can be DDoS'ed to death.
And if using my suggested technique to create a hash-based signature as a first line of verification of incoming transactions sent to the block chain, then you've got to incorporate a simultaneity mixnet such as CoinShuffle to detach these hash signatures (and the payee's IP address) from the Zerocash transaction being submitted to the block chain. But then your anonymity is reduced back to the mixnet again so you've lost the benefits Zerocash provides. Perhaps Zerocash could devise a quick check on invalid signatures. I don't enough about the "moon math" in the white paper to deduce whether that is possible, but I 95% doubt it based on my understanding that such NIZKPs are a holistic math affair.
Perhaps instead of my hash suggestion (and as suggested by Gregory Maxwell at the aforementioned linked thread), each Zerocash (or RingCT) could require some PoW be attached to every transaction to rate limit spam, but the problem is the attacker has an asymmetric advantage by being able to place his hashing resources in venues with the cheapest electricity (e.g. 3 - 4 cents per kWh in WA State or China near hydropower) and leverage the latest ASIC efficiencies whereas the legitimate payer is running on retail electricity that costs 4 times more and non-optimum hardware that is at at least an order-of-magnitude disadvantage in power and speed. So the delay (or the transaction fees if the full nodes speed more on hardware to increase their spam bandwidth) will increase for legitimate payers asymmetrically to the attacker's costs. And that asymmetry will be amplified by the systemic ratio of the resources of the legitimate payers to the attacker's resources, thus if the anonymous system is only used infrequently then the cost of using it will be radically amplified (perhaps too high to be of practical use, although I haven't done some sample calculations yet). And for the system to be widely used (e.g. for microtransactions) the extra costs imposed by the attacker disincentivize its use when the legitimate participants don't value anonymity as a concern. Also the PoW required could vary per full node and vary in time (even in real time!) depending which nodes are receiving the most incoming DDoS spam, which complicates the determination where to submit a transaction and how much PoW is required to be submitted with it. So then it appears any any such Zerocash + PoW anti-DDoS system is going to be used only for anonymous mixing and not all transactions, but then the problem is the anonymity leaks as these anonymous mixes are then traded for coins in a system that is used in everyday commerce (e.g. microtransactions).
Even though I haven't thoroughly understood every technical aspect of it, the other problem with Zerocash appears to be that it can't merge the entirely opaque block chains, e.g. if there are two major chains fork due to a network split. Transparent block chains can be re-merged to the extent that double-spends are not intertwined. The major fault for Zerocash (that is not present for transparent block chains) being that I believe it is not possible to prove which coins were double-spent on both of the block chains. Normally this isn't a problem for an orphaned chain because you just throw away the orphans, but this is perhaps a problem in a major network split.