How do you prevent Sybil attacks-- somebody creating a gazillion n-client and/or hatching nodes, and voting themselves lots and lots of new currency?
And how does a node choose a "random" node-- does every node know about every other node? If yes, then how do you avoid getting O(N^2) communication as the number of nodes (N) rises and every existing node must be told about every new node?
I'm composing an amendment to the OP regarding Sybil like attacks and the prevention of them as a few members have raised this point both public and private, I'll be appending it shortly after I've finished up some other tasks. Hopefully that will then give an idea how we handle it.
Selecting a random hatching node doesn't require the peer to know about all of them, or about any other client peers in the system. A voting peer can either select a hatcher from its currently connected peer pool (if there is one or more present) or send a request to a seeder node which has a collective store of all the most recent nodes within the system (as its seeding it is able to do this easily), including plain client peers, hatchers and other seeders. As peers and hatcher connections come in and out of this peer pool, that further massages the entropy of the hatcher selection.
With the voting system it is possible to have many hatchers, all obtaining votes from the client peers independent of each other, and deciding, independently also, whether to create a new currency unit or not. Currency regulation is determined by using the public ledger, so providing that all the hatchers collecting votes are close to being up to date, they will all be working to the same vote threshold.
As the system grows hatchers will be working with a subset of the total voting power in the system, but the required target volume can still be met and held.