Descriptor fingerprint format
rransom.8774 at gmail.com
Fri Oct 29 05:25:28 UTC 2010
On Thu, 28 Oct 2010 20:23:17 -0400
grarpamp <grarpamp at gmail.com> wrote:
> Descriptor fingerprints look like this:
> opt fingerprint 0001 AC1F 9AE6 9A00 3C5E 6F02 73CB D69E C6E7 6926
> opt fingerprint FFEB 470C F379 9E9C 5956 8521 8627 9ED5 55AB 1340
> It's an extra routine to remove or add the spaces for scripting, with
> the control port, etc. And who really uses them in a human fashion
> with spaces anyways, this isn't a keysigning party :)
> It also uses about 9 spaces x ~3300+ descriptors ~= 30,000 bytes
> of traffic for one client to pull the entire relay list. Multiply that
> by number of clients[?] x the frequency[?] ~= bandwidth wasted.
> Maybe another ~10,000+ bytes x clients x freq could be saved by not
> publishing the junk after the first left bracket '[' in the windows
> platform lines.
> Any ideas on removing these two someday?
Very unlikely, unless someone hands it to us before Tor's cryptographic
algorithms need to change. The descriptors and consensuses are
compressed, so it's less than 9 bytes per fingerprint, and the format
that Tor relays emit can't change unless all Tor clients can read the
new format. (A change in cryptographic algorithms would probably lead
to a break in backwards compatibility sometime later.)
There are also bigger wins -- base32 or base64 fingerprints, for
example. (Base32 would be better for router fingerprints, because that
can be cut and pasted into the .exit notation to select an exit node.
Base64 can't be used in .exit because DNS does not preserve letter
If you really want this to happen, write a proposal, and start writing
a patch to the parsing code.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the tor-dev