The hatcher that is selected and the vote (yes or no) are handled by the client software. The actual wallet holder has no control over this at all.
That's meaningless from a security mindset. If it's open source, people can change the client software, heck, even if it's closed source, people can change the client software with enough effort.
If you were to grab the source and modify it to always vote yes, then even if there were only 100 other voters in the system, you vote can only skew the vote by 1%, which isn't enough to cause damage and will only push up the vote threshold over time.
So now we're back to "what magical algorithm are you using to stop Sybil attacks?"
I'll explain further, as no "magical" algorithm is needed to prevent runaway creation volume of units, and to overcome nature of how it works to benefit, you would need to own, or control the entire network. That's all client peers, all seeders, all hatchers, to ensure that the fruits of your attack were beneficial, then its no longer decentralized anyway, so then it would die.
Anyway, lets say that current vote threshold is 50%, that is, 50% of the votes in need to be yes to create a new unit. To force a hatcher to create a new unit, you would need to have more than 50% of the vote power to that hatcher (disregarding any others in the system).
Assume that you have managed to pin down a few hatchers, and you flood them with votes from many clients to push the vote 50%+ so new units are created. That will likely move the created unit volume up past the required target the network, so hatchers in the system (including the ones you have pinned down assuming you don't own them) will adjust up from 50%+ yes vote, to say 75%.
You perform the attack again and again until the vote threshold is 90%+, that essentially cuts of the creation of the units, because the volume is ahead of where it should be, so no new units will be created until time catches up.
If you
DO control the hatcher to always create a coin, you need the signed votes which are verified later, you can only create 60 units at a time, otherwise other hatchers and clients will reject it, and you can only create once every 60 minutes, otherwise other hatchers and clients will reject it.
Creation of a new unit (coinbase in BTC terms) has a record of all the yes voters, with their votes signed. When that block goes out in to the wild and is re-verified by other hatchers, those voting nodes can be contacted and asked if they indeed voted yes to create that unit, if you control all the voters to that hatcher too, then yes you could falsely create a 60 units.
So you have created 60 units ahead of time, dishonestly, but unless those units are distrubuted as required by the system, those units will again, be rejected by others in the network.
I could continue, but that should give you an clearer idea how its "difficult" to game it unless you are running a lot of the network both in client peers and hatchers.
