[tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

David Goulet dgoulet at ev0ke.net
Fri Jan 27 15:09:41 UTC 2017

On 27 Jan (09:04:51), chelsea komlo wrote:
> Hello!
> I have some more thoughts on versioning, specifically in regards to the
> possibility of not including the version in the onion address and using
> only the version field in the descriptor.
> I'm not able to write out these scenarios now but I will do this in the
> next day. Thanks for making last call!

Here is some extra pressure for you ;).

The HSDir fetch/post URL has gone in 0.3.0 (feature freeze today in theory ;)
with the version in it:

    --> /tor/hs/<version>/publish

So few things. First, if we don't have the version in the onion address, this
means the client needs to try to fetch the descriptor for multiple version
that is starting at the highest it knows and then going down as it's failing.
That, I'm really not too keen to this, uneeded load on the network.

Second thing is that HSDir might not all support the same version by the time
we roll out prop224 thus the importance of having it in 0.3.0 (a version
*before* the next gen release). Even with that, this is going to be an
interesting experiement to have a set of HSDir supporting v3 and a set not
supporting it because we kind of have this requirement of using 3 nearest
relays for a replica but what if one of them doesn't support v3?

Third thing, we could have a fix for this with a single descriptor supporting
multiple version but then this has implication outside the onion address
discussion and unfortunately 0.3.0 material again (that freezes today).

So I'm eager to hear your idea on this! But it's important to keep in mind
that 0.3.0 has already some building blocks with some version restrictions :S.
Changing those would mean delaying adoption by a 6 months (and it could be


> Chelsea
> On 01/27/2017 08:09 AM, George Kadianakis wrote:
> > David Goulet <dgoulet at ev0ke.net> writes:
> >
> >> On 24 Jan (14:27:43), George Kadianakis wrote:
> >>> s7r <s7r at sky-ip.org> writes:
> >>>
> >>> <snip>
> >> I like this quite a bit! Simple, easy, and trivial to understand. 56
> >> characters address, after that it will be the time to improve UX/UI with all
> >> sorts of possible tricks to make them easier to remember or copy paste or
> >> visualize or what not.
> >>
> >> Unless some feedback NACK this, I say push that in the proposal soon. I'll
> >> personally start implementing that scheme this week.
> >>
> >> Thanks!
> >> David
> >>
> > Hello,
> >
> > I made a torspec branch that alters prop224 accordingly:
> >   https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224-onion-address&id=50ffab9903880acf55fe387f4d509ecb2aa17f95
> >
> > I will merge this to torspec RSN if I don't hear any grave objections.
> >
> > Cheers!
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170127/78962e6b/attachment.sig>

More information about the tor-dev mailing list