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

[George Kadianakis <desnacked@xxxxxxxxxx>]

grarpamp <grarpamp@xxxxxxxxx> writes:

> Skimming thread...
>
> Version or not is fine, provided if you want versions you
> know you must store the bits somewhere, or ensure regex
> parser rules to recognize and match an intrinsic version
> represented by entire address format specification itself.
>
> Note onion search spiders rely on such address recognition
> and parsing. So it's not all just about the browser brain urlbar.
>
> GPU capacity hasn't hit 16 char yet, mnemonic
> brain memory has, but that's only happened based on
> address luck and/or GPU prefixing. We're more or less
> at the limits, new random bits past 16 won't matter and
> shouldn't be considered much an argument to brain relavance.
> Some other brain layer will come along, and if not, there's
> always search.
>
> If version goes in address, I'd wary against putting it last.
> A lot of things naturally sort and route and default based
> on higher order bits appear prefixing on the left.. IPv4 IPv6
> bitcoin PTR DHT filesystem unix tools... the list goes on.
> A single leading character is not a problem and gives
> plenty of bits of version capacity regardless of encoding.
> Trailing version just plain feels shaky to rely on or to
> advocate to the world as a new standard. Certainly
> not without consultation with other anonymous overlay
> projects as to their future needs and direction as well,
> or to develop such an interop standard.
>

Hm, can you please expand on this? I think I understood none of your arguments.

What's the problem with version field being in the end and tools sorting
addresses based on higher order bits? Also why does version field being
in the end makes it shaky to rely on?





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