A ha! End-to-end identity anonymity is possible!
The reason identity anonymity can't be done end-to-end principle (Zerocash almost does it, but as I pointed out there is
a DDoS weakness incurred), is because our IP address is an identity that we can't easily detach from ourselves. For all other forms of data privacy, the IP address problem is irrelevant.
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.
There is a simple solution for DDoS with Zerocash. Use
my hash-based signature suggestion on a non-anonymous basecoin, when sending the anonymous zerocash (the Zerocash paper names these zerocoins, not to be confused with Zerocoin) transaction. Since on a spend transaction (aka pour) the anonymous coins are entirely mixed with all anonymous coins, then your IP address and your non-anonymous transactions do nothing to help anyone trace the anonymous coins. And putting the non-anonymous funds at-risk with the fast to verify hash-based signature (3 million verifications per second on an 8 core CPU!), solves the DDoS attack issue.
Alternatively it may be possible to mint the hash signatures in such a way that the anonymous coins are forfeited when doing a DDoS attack, but are still not non-anonymously linked to the hash based public key, instead of needing to use a separate non-anonymous basecoin. This would be preferred for permissionless commerce.
So thus unlike RingCT, no CoinShuffle (mixnet) would be needed. Unlike Cryptonote (and RingCT), Zerocash hides everything because the inputs to the NIZKP are never revealed! This is the advantage zk-SNARKs because it proves that a program compared the inputs in the desired way, without revealing what the inputs were. Whereas in CN and RingCT, we all see the input public key addresses and the proof of which public address is spending is obscured by the mix, but correlating the IP address across mixes can correlate which of those addresses were in both mixes. For CN and RingCT to be as anonymous as Zerocash would require they mix with all known (and future!) public key addresses.
Note that zk-SNARKs are very slow to verify (roughly 300ms for a Zerocash transaction) and consume more bandwidth so this can't be used for all transactions. It would be a mixer that you mint non-anonymous coins into when the slow verification and its higher fees are justified.
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.
Apparently I am mistaken. Zerocash coins have serial numbers, so it should be possible to know which serial numbers have been double spent on both forks.