I really don't understand the rationale behind these hybrid PoS/PoW systems. You can either solve the Byzantine consensus problem with proof of stake, or you can't. In the first case there's no need for wasteful proof of work. In the second case it makes no sense to complicate the design with something that does not add security. It's as if the designers want PoS, haven't quite figure it out how to achieve it, and add PoW for good measure just in case their PoS scheme turns out to be vacuous.
The same can be said about the baroque "polymorphic" hash. If your goal is memory hardness and a small performance opportunity for custom hardware, you should design a scheme specifically tuned for CPU implementation - if such a thing is indeed possible. A hodgepodge of all hashes under the sun while hoping the ASIC designers won't bother to implement them all is security through "copypasting lots of code".
I was really hoping there would be at least one major naysayer in this thread to think about things to improve the chain, but I'm not sure I'm following your argument.
Any solution to the byzantine consensus problem with a hybrid PoW-PoW stake system that further introduces fault-tolerance and enhances network security with no real net increase in computation power should be a better solution, not a worse one (main tradeoff is chain bloat, but I'm sure people find this acceptable). In MC2 there are two new mechanisms of fault tolerance: (1) Multiple secure hash algorithms (2) The requirement of at least some coins (very large amounts as the chain matures) that are 90 days old
in addition to 51% of the network hash rate. The first addresses any potential failure of SHA2-256, while the second addresses double-spend attacks created by short forks of the chain. In this way the hybrid PoW-PoS system is a better solution to the byzantine consensus problem as far as I can tell.
There's too much on the CPU that will never be used for encryption schemes for obvious reasons, such as the FPUs. The same goes for GPUs. Encryption algorithms need to be totally invertible, so they are forced onto the ALUs. I'm not going to write my own secure hash algorithm when we already have several viable ones that have been poured over for years by extremely intelligent people -- it's unlikely I'm going to make one that's more secure than the ones already available.
I'm not sure I follow the "copy-pasting" argument either. Yes, I'm adding more hash algorithms -- but there is no simple way to implement them all together with an ASIC or FPGA without using a massive number of logic units. You're looking at maybe 35k gates with a scrypt ASIC while this would easily require 100k+ to hit all encryption algorithms. You can tune one for just one or two of the algos, eg Chacha20-BLAKE512 and Salsa20-BLAKE512, but even attacking with a vector like that gives you 25% of the network if you had some insane amount of them; this is not enough to attack the network with a 51% attack. Further, you have the design hassle of having to optimize for random values of N within a range of 512-2560, and you also have to do the hard hashes to determine the order and quantities for N-values for the upcoming blocks (requiring a CPU or GPU at some level in the easiest implementation).