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

[chelsea komlo <me@xxxxxxxxxxxxxxxx>]

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?

> [D1.1] Default version value:
>
>       The next question is what version value to assign to normal onion
>       services. In the above scheme where:
>
>          onion_address = base32(version + pubkey + checksum)

It would be good to understand what the process of upgrading default
versions looks like, from both a client and hidden service operator
perspective.

Thanks, great work!
Chelsea

[1]
https://en.bitcoin.it/wiki/Address#A_Bitcoin_address_is_a_single-use_token

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev