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