...snip...
Of course, everything I'm saying is just off the top of my head, but without any serious statistical analysis on the part of those that say this is a reality - a 51% attack with less than 51%, or even with 61%, as has been said here - what I'm saying holds the same weight (if not more since common sense tells us that less than half is not equal to half).
Common sense tells us that a 51% attack requires a 51% control of the ENTIRE network, not 51% of 20% of the network, unless you're able to stop the other 4 algos from discovering new blocks over a short period of time, something which no-one has ever said is possible (will this be the next shoe to drop?) and something that doesn't happen regardless of how much one individual algo's hashrate spikes.
...snip...
This made me laugh - especially the part about what you're saying holding even more weight because it's based on "common sense". No offense, but no amount of "common sense" can match up to having read (and written parts of) the source code. Let me do my best to break it down:
If you mine a block using SHA256d at difficulty 1000000, the network says this block contains 1000000 "work units".
If you mine a block using Scrypt at difficulty 30, the network says this block contains about 120000 "work units".
If you mine a block using Groestl at difficulty 200, the network says this block contains about 100000 "work units".
If you mine a block using Skein at difficulty 1000, the network says this block contains 24000 "work units".
If you mine a block using Qubit at difficulty 40, the network says this block contains about 40000 "work units".
If one block of each algo is mined every 150 seconds on average, this amounts to 8560 "work units" per second by the main network.
Now consider an attacker with enough hashpower to maintain the SHA256d difficulty at 1300000 (without the rest of the network). At one block every 150 seconds this amounts to 8666 "work units" per second. Therefore, the attacker can produce "work units" at a faster rate than the main network, and use this to mount a 51% attack against the coin.
So what about the one-cpu attack? Well, at the time Myriad was taking the sum of the difficulties (without the multipliers) as the "work units". In the above example each block would contain 1001270 "work units", regardless of which algorithm was used. The attacker chooses a starting point for his chain when the SHA256d difficulty is high, and because he doesn't mine SHA256d the difficulty for that algo doesn't change. Eventually, the attacker's blocks have difficulties that look something like (1500000, 1, 1, 1, 1) and generate 1500004 "work units" per block, despite the attacker actually mining at difficulty 1. The dev team fixed it by adding a decay step to the work calculation - if too many blocks go by without a particular algorithm finding a block, the "work units" provided by that algorithm are reduced (possibly all the way to 0). But Myriad is still vulnerable if the attacker has slightly more than 50% of the SHA256d hashrate.
So how do we solve it? In the DigiSpeed branch, "work units" are calculated by multiplying all of the difficulties, then taking the 5th root. For the example difficulties at the top of this post, it works out to about 750 "work units" per block. But if an attacker has enough hashpower to maintain the difficulties at (9000000, 15, 100, 500, 20), his blocks contain only 670 "work units" each, even though he controls 90% of one algorithm and 33% of the other 4 algorithms. Note that pre-DigiSpeed "work units" are not directly comparable to post-DigiSpeed "work units", and the code contains a fudge factor to make sure the coin isn't vulnerable during the transition.
... soon...