On 05/02/17 07:44, Taylor R Campbell wrote: >> Date: Sat, 04 Feb 2017 20:14:00 -0600 >> From: Vi Grey <vigrey@xxxxxxxxxx> >> Also, should we consider including a Version option eventually in the >> ADD_ONION control port command when using a KeyBlob? It wouldn't matter >> much for this new version and probably wouldn't matter much for a while, >> but it might be good to keep this in mind for the future. > > Versioning onion addresses and versioning network-internal service > descriptors need not be done the same way. > > Addresses are likely to be long-term, and should really change only if > the meaning of the encoded public key has changed incompatibly but > otherwise imperceptibly -- e.g., if for some reason Tor switched from > Edwards coordinates to Montgomery coordinates on Curve25519. (That > would be a silly thing to do -- it is just an example of a change that > could still interpret existing addresses, but differently.) It seems to me that different people in this thread have different ideas about what the version number in the onion address represents, and it would be good to make that explicit in the spec. Does it represent: 1. The version of the *onion address format* - meaning that, for example, a v4 address and a v5 address could point to the same descriptor, which would be compatible with both addresses? 2. The version of the *descriptor format* - meaning that a v4 address must point to a v4 descriptor, but a v4 descriptor and a v5 descriptor could point to the same hidden service, which would be compatible with both descriptors? 3. The version of the *entire protocol* - meaning that a v4 address must point to a v4 descriptor, which must point to a v4 hidden service? Cheers, Michael
Attachment:
0x9FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev