[3SidedSquare]

1. Yes, the worry is that a peer can just request over and over until they have a map of the entire network.

I'm sitting here racking my brain, and I've thought up a few solutions

Solution 1:

Spoiler:

Unsecured nodes keep track of all clients they have had. When a secure peer tries to enter the network, the unsecured peer they connect to broadcasts a message checking if anyone has the secure peer on their "list of secure peers that have connected to me". That way secure nodes only get new unsecured nodes when 'their' old node(s) go down.

Very susceptible to peer poisoning

A computer running 24/7 can probably get a chunk of the network anyway

Solution 2:

Spoiler:

When the bot spreads, only give it 5 or so unsecured nodes. If they all go down, the bot is dropped.

Lots of bots will drop over time

Solution 3:

Spoiler:

Have a list of secure peers that have requested some new unsecure peers recently, if one peer is requesting more than once a hour/day/week/month, don't give him any new peers.

May take up a lot of space on the unsecure peers

I'm thinking about going with option 1, opinions?

2. But the public key is derived FROM the private key, so its only asymmetric to someone not willing to compute the public key from the private key. By encrypting a message to the node, but signing it with an admin key, you authenticate that the command came from the holder of the admin private key, and the command is secure from outside eyes.

I don't think this is always the case, but anyway I've found an algorithm that I think will satisfy,
http://en.wikipedia.org/wiki/ElGamal_encryption