One thing that I would like to point out is that .onion addresses will always contain a public key, and we want to keep them short. This means ECC (un)fortunately, but apparently DJB has an unencumbered implementation. The other thing I would like to note is that when we extend a relay, we are going to reveal something about the client if we use a protocol version number that is externally visible to the passing relay. I don't really see a way around this given that the next relay needs to know in what format the remainder of the data is in the packet
So I think we also have 2 separate problems here. Problem 1 is this upgrade, and Problem 2 is future-proofing. Unfortunately they feed into each other. What we could do is (depending on how tor responds to unused commands) is defined EXT_CREAT as packet number 10 which has the format CircID 2 bytes 10 1 byte SUITE 1 byte, 0 for this revision. PAYLOAD fills remainder of packet. When a client receives indication that its EXT_CREAT was not recognized it falls back on CREATE. ORs send back a packet that indicates if they do not recognize the SUITE and the client falls back to an earlier revision. It is important that all clients support only 2 methods to avoid massive fracturing of the anonymous set. ORs probably also should also do this. Anyway, that is my 2 cents. Sincerely, Watson Ladd
