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

[George Kadianakis]

chelsea komlo <me at chelseakomlo.com> writes:

> Hey George,
>
> Thanks for sending this and summarizing everything!
>
>> [D1] How to use version field:
>>
>>       The version field is one byte long. If we use it as an integer we can
>>       encode 256 values in it; if we use it as a bitmap we could encode
>>       properties and such.
>>
>>       My suggestion is to simply use it as an integer like Bitcoin does. So we
>>       can assign value \x01 to normal onion services, and in the future we can
>>       assign more version tags if we need to. For example, we can give a
>>       different version field to onion services in the testnet. We can also
>>       reserve a range of values for application-specific purposes.
>
> Will hidden service addresses only encode a single version?
>
> If yes to the above, only allowing a limited number of versions on the
> network at a single time might be a good idea. Otherwise we run into the
> dilemma where hidden service operators need to maintain and distribute
> multiple addresses, and users need to understand what version their Tor
> client supports (and potentially their friend's as as well, if they want
> to share a HS link).
>
> As s7r said, Bitcoin addresses are single user/single use [1], whereas
> HS addresses are multiple user/multiple use. Because of this difference
> in purpose/use, I would argue we'll need to consider circumstances such
> as version incompatibility, upgrade path, longevity, etc more strongly
> for HS addresses than for Bitcoin addresses.
>
> The idea of supporting multiple versions in a HS address was discussed
> earlier- is this still a viable scheme, or did the cons eventually
> outweigh the pros for this?
>

Hey Chelsea,

while writing the proposal, I felt like supporting multiple versions in
the version field would be more trouble than worth it. I also dislike
the fact that multiple addresses could then represent the same public
key.

Also, I doubt we will ever reach the point where we have multiple HS
versions existing simultaneously in our network that can also share the
same onion address.  This time, we will have two versions, the legacy
onion services and prop224; and their addresses are definitely incompatible.

Worst case, if the need for this becomes apparent at some point, we can
abuse the integer valued version field to encode such information (hey,
we have 256 values after all). Or perhaps this is the best case since it
means that the hidden service protocol has evolved a lot...

Cheers!