On Thu, 24 Nov 2016 01:43:15 +0200 s7r s7r@sky-ip.org wrote:
I agree that this would be "the technical way" to do it, but real world usability kind of prevents us to do it this way. The spec for ADD_ONION indeed does not say that v2 hidden services will be supported forever and it clearly SHOULD NOT, but it also doesn't make much sense to abolish it at the first Tor release supporting v3 services (because if we make ADD_ONION == v3 (best) this is what we are doing).
Even I don't think `BEST` should be changed to Ed25519 immediately, especially when the code is being stabilized.
That is a completely orthogonal to the fact that people that have dumb limitations like:
Bitcoin Core - latest versions detect if you use Tor and automatically use ADD_ONION to create v2 services, and, important: it doesn't support yet the v3 address types because of their length. This way people behind NAT running it can be better connected by accepting incoming connections without an open port, some people don't want their upstream provider to know they are using this app, etc.
Should be using `NEW:RSA1024` explicitly. The override is there for a reason, and the key type is part of the serialized data that tor returns to you when you have it generate a key, precisely to avoid this sort of problem.
Their fix: "Replace line 473 of bitcoin/torcontrol.cpp with `private_key = "NEW:RSA1024";`".
Our fix: "Add another command, that does essentially the same thing, because people picked the wrong options, then later deal with the fallout from people getting used to the temporary command, and crying when it's deprecated."
I say "they should fix their code".
I don't think it's productive to ask users to already support a new feature upon our first release providing the said feature.
If they aren't using existing interfaces correctly, when correct behavior has been part of the interface since support for it was added, quite frankly it's their problem.
Regards,