-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Scott,
Scott Bennett wrote: |> The default of 24 hours ensures that hidden service directories are |> available for the next few hours with a certain probability. The idea is |> that there are hundreds of hidden service directories at some point |> which are not authoritative any more, but provide a more scalable and |> robust storage than the three authoritative ones can. Hidden services |> and clients need to have a view as consistent as possible of which |> hidden service directories are out there, so that clients can find |> previously stored hidden service descriptors. The 24 hours have turned | | How is that different from the situation of normal directory mirrors? The big difference is that every hidden service directory is responsible for a certain set of hidden service descriptors and not all of them. If you run a hidden service you determine six responsible hidden service directories depending on a) the onion address of your service and b) the node identities of the hidden service directories. Then you store your descriptor on exactly those directories. Your clients need the same or at least very similar information about hidden service directories as you have. If their list of directories contains further directories or misses some of those that you know, your clients will end up requesting your descriptor from the wrong directories. A further difficulty comes from the fact that your clients and you might use consensuses with up to two hours time difference. A certain number of differences is tolerable by performing replication, but these shouldn't get too big. | In other words, it is already covered by the "Guard" and "Stable" | flags from the authorities, right? These flags have different purposes, and their definitions might change in the future (as might the definition of "HSDir"). Apart from that there needs to be an "HSDir" flag anyway to denote which relays want to participate in the hidden service directory. Admittedly, a further evaluation could compare the approach taken here with your approach to derive usefulness of a hidden service directory from "Guard" and/or "Stable" flags instead. Honestly, I don't know what the result would be. Seems that there's always work left to do. ;) |> http://freehaven.net/~karsten/dirnodesminuptime.pdf | | It's very pretty, but, given the legend, which I assume denotes | uptimes in hours, the axis labels are not helpful. What exactly do | "Directory Size" and "Time Index" refer to? "Directory Size" refers to the size of the distributed hidden service directory, assuming that *all* relays that have their directory port open work as hidden service directory. Of course, this number differs significantly from the current number of hidden service directories. That's why one proposed change of proposal 143 (which is planned to be implemented in 0.2.1.x) is to make all relays with open dir port act as hidden service directories by default, with the possibility to opt-out. "Time Index" is admittedly a bad axis description, which however comes from the fact that I didn't know how to write month names at the appropriate places of the x axis in R. :) The x values denote the hours of evaluated consensuses between mid-January and end of March. The peaks that you see for minimum uptimes, e.g., of 4 to 16 hours are the days in that interval. Now compare the peaks of using no minimum uptime at all with those of requiring an uptime of 24 hours. If there would be no requirement for minimum uptime, replication would have to be increased significantly. |> The option MinUptimeHidServDirectoryV2 is mainly there to perform tests |> with the distributed hidden service directory without having to wait for |> 24 hours. It is not required to set it in the public Tor network. (It |> only has an effect on directory authorities anyway.) | | I understand that, though it is also useful for the operators of the | current authorities should the policy change. What I still don't see is | the need for a 24-hour delay before a server stops being only potentially | useful and becomes actually useful. Earlier today the HSDir count was | down to only *4*. How is it thus helpful to keep other servers from being | available for use? I think I have already answered these questions above. If I should have left out something, please ask. Hope this helps a bit more now. :) - --Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFImcwL0M+WPffBEmURAiUkAJ9MIRiesdLEenA9BxSJJ4T6mC2fZACfYWNT 2Net1ADWsE/ywa7V1l4Iqtw= =IlPj -----END PGP SIGNATURE-----