Well I think that just through system-backups, maintenance, restarting etc. that the descriptor upload times would be fairly random anyways, especially if a random-turn-off function was implemented. Comrade Ringo Kamens
On 8/8/07, Robert Hogan <[EMAIL PROTECTED]> wrote: > On Wednesday 08 August 2007 19:32:39 Ringo Kamens wrote: > > I'm interested in testing this out with somebody. Until then, can any > > devs/tor hackers enlighten us as to what would determine which host > > gets picked? Would it be whoever is the fewest hops away? If so, one > > host would get the most traffic if it was consistently closest to fast > > servers. > > Comrade Ringo Kamens > > > > The spec says: > > Upon receiving a descriptor, the directory server checks the signature, > and discards the descriptor if the signature does not match the enclosed > public key. Next, the directory server checks the timestamp. If the > timestamp is more than 24 hours in the past or more than 1 hour in the > future, or the directory server already has a newer descriptor with the > same public key, the server discards the descriptor. Otherwise, the > server discards any older descriptors with the same public key and > version format, and associates the new descriptor with the public key. > The directory server remembers this descriptor for at least 24 hours > after its timestamp. At least every 18 hours, Bob's OP uploads a > fresh descriptor. > > So if a number of servers shared the same hidden-service key they would just > overwrite each other's descriptor with each upload. They would never > co-exist, instead the most recent poster would get the traffic. > > It seems like it should work as long as the servers agreed to update at > different times. Not sure how secure such a service would be though. > > > -- > > Browse Anonymously Anywhere - http://anonymityanywhere.com > TorK - KDE Anonymity Manager - http://tork.sf.net > KlamAV - KDE Anti-Virus - http://www.klamav.net > > >