Length of new onion addresses

[Michael_google gmail_Gersten]

Length is not nearly as important as bookmarkability. You mentioned
that you are going to be changing stuff every day. That worries me.

> his service. Though, the effect of this is limited, because descriptor
> ids are automatically changed every day. My idea was to use 32 bits for
> the service id.

Your other ideas: Breaking things into parts:
> For downward compatibility reasons, those 200 bits could also be
> distributed by using 80 bits for the service id and 120 bits for the
> secret key. Then, people could start using the new descriptor by simply
> adding a dot and a secret cookie to their current (unchanged) onion
> address. This would look like this:
>
> http://6sxoyfb3h2nvok2d.6sxoyfb3h2nvok2d6sxoyfb3.onion/

I like this much, much more.

> Maybe we shouldn't even extend the onion addresses at all, but allocate
> the 80 bits in another way, e.g. 24 bits for the service id and 56 bits
> for the secret cookie? Then we should use another virtual top level
> domain to distinguish current and new descriptors, resulting in
> something like the following:
>
> http://6sxoyfb3h2nvok2d.hidden/

I think this is the best. Use the current system for sites using the
old method (central servers mapping .onion addresses to introduction
points), and a onion.secretkey.hidden for stuff using the new,
non-central servers.

> What do you guys prefer? How do you exchange onion addresses? Publishing
> them on non-hidden web pages, pasting them to IRC chats, writing them on
> business cards, memorizing and telling them, ...? I think it's important
> to find a balance between security and usability here.

Business cards? Hadn't thought of that. Yea, that would give a bonus to short.