There are more than one hatcher, so on aggregate, the big picture will give you clear patterns of honest profiles.
Assuming, of course, that on aggregate the hatchers are honest. When dishonesty can lead to profitability, this is very unlikely to remain true.
It's not possible for the cheater to choose which hatcher to handle it's transaction.
I'm going to straight up call bullshit on this until someone from emunie shows how this is possible. It doesn't even make sense.
Plus even if they do manage to cheat through Ip and Mac adress as you described, there will be lots more signals they can't game, such as EMU age, graph, and so on
If the "graph" algorithm is open source, it can be gamed. As I mentioned to brenzi, the bitcoin theft was only obvious because the perpetrator was unaware of how his transactions could be analyzed. Under emunie, a dishonest person will know exactly what behavior the network is looking for, thus making it trivial to avoid detection.
Re google centralization: sure keeping the info private does help, but that doesn't mean they are not known to spammers. Quality rating guidelines of Google leak out to the web every now and then. But that doesn't matter.
It doesn't matter because then google can change the parameters to something else without the spammers being able to stay ahead. This is not possible in an open system.
(each EMU unit can have a stamp separate from the wallet it belongs too to identify it's mint date, for example.).
No, it can't, unless you throw any notion of scalability out the window. It is easy to say something is possible, but when it comes down to implementation, this is not going to be a protocol that will be useful on any sort of reasonable scale if you have to keep track of kilobytes of data for every little gameable metric multiplied by millions or billions of transactions, or to check hundreds of thousands of prior transactions to determine how each divisible unit of a transaction has arrived to where it is today.
The key is not whether it is centralized or decentralized, it's about giving more incentives for people to cooperate.
"Yes, emunie intends to be a centralized protocol." This a monumental failure in design. You may as well drop all these shenanigans and have a central server--it would certainly be far simpler.
If fuserleer thinks your ideas bear any consideration, combined with his
poor understanding of the double spending problem, I do not foresee emunie being a viable currency. But the details are so scarce at this point I could be convinced the code is nothing more than a hamster running on a wheel.