Enhanced Synchronize Rules
I was poking around with a bunch of daemons on my computer and noticing that synchronization didn't always happen right away, but once things were synchronized they seem to maintain it. So I wanted to suggest a few rules and see what you think.
One thing that was apparent is that if you don't have peers (but peers have you), you will fall behind. You call resynchronize but it doesn't help you because you don't have the peer who sent you the block. Basically, relationships aren't reciprocal. If you get something unknown, you should ask the person who sent it to you for more information, even if you don't have them in your peer list. (I think. I'm not sure how DoS plays into this). Because I'm not sure about DoS stuff, this didn't get a number.
- Synchronize should be called upon getting a new peer, on the new peer. I don't think this is currently the case, even after adding peers I had to manually call 'synchronize'.
- Synchronize should go both directions. Or rather, when someone calls synchronize on you, there should be something that checks if they have blocks you don't recognize. If they do, you should call synchronize on them. Maybe this is overzealous and unneeded.
- Peer adding should be reciprocal. I know we had worries about this in the past, but I was thinking you should be aggressive about finding peers when you have less than n. (n = 12?) If you m peers and m > n, you should add the peer with probability 1/(m-n), and otherwise put them in some container so they can't just call add on you 10000 times to guarantee they'll make it. Once you've rejected them the rejection is permanent. Anyway, up to some number of peers, you should add anyone who adds you.
- When requesting peers, you should ask everyone you know for a list, and then from that aggregate you should randomly select peers until you have N total (12?)