On Wed, Feb 01, 2017 at 09:36:54AM +1100, teor wrote:
On 1 Feb 2017, at 01:36, David Goulet dgoulet@ev0ke.net wrote:
On 31 Jan (09:02:35), teor wrote:
On 27 Jan 2017, at 01:58, David Goulet dgoulet@ev0ke.net wrote:
However, there is kind of an issue rising from this. Imagine that v4 changes the onion address format because new crypto. We'll end up with a problem where the how to extract the version from the address is actually version specific... A solution to that is that "whatever size/encoding the address is, version will ALWAYS be the last 1 byte."
Thoughts?
I think it is a good idea to make the version the last byte of the address.
Sure, if stays here it's effectively a version suffix (label). Another version will imply address length, encoding, checksum, etc.
But I also think that a version file is a good idea to make it easy for applications to discover the on-disk version.
Otherwise, the algorithm would have to be something like:
- look for a hostname file
- read the first line
- find the address in that line
- if the address is N characters long, version 2
- do we promise we will never have addresses this long in future versions?
- base32 decode that line
- do we promise addresses will always be base32?
- read the last byte
- do we promise addresses will always have the version in the last byte?
This entire idea to do something for some apps to detect onion service version "just by looking at disk" looks like a feature creep to me. Why should we bother at all while we have onion address that is self-descriptive?* It's not a big deal really to parse onion address from a 'hostname' file. Especially for an app that wants to know the protocol version (what for?). Personally I belive that there are no(t so many) apps that would mess with onion services without using an onion-related library such as stem which will make it as simple as one function call over onion address.
[*] Yeah, for that there should always be Base32 and version byte at the end. -- Ivan Markin