chelsea komlo me@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!