Yes correct, using hidden services just as a kind of more complicated, out of process/sandboxable SSL.

 

If all nodes talked to each other all the time over Tor, probably yes because Bitcoin is quite sensitive to latency. But what I'm proposing here is less ambitious. It's just about protecting (parts of) end-user-to-network communication, which is a much less risky sort of change. P2P nodes would still talk to each other in the clear.

SSL for everything is still an idea I like, but it's true that increasing bitcoind attack surface area is not something to take lightly.

Considering that the clearnet sybil protection also relies on scaling
up the resource requirements for an attacker, why not require hidden
service addresses following a certain pattern, like a fixed prefix?

I'm sure we can come up with all kinds of neat anti-sybil techniques, but IMHO they are separate projects. I'm trying to find an upgrade that's small enough to be easily switched on by default for lots of users, today, that is low risk for the network overall. Later on we can add elaborations.

Right so the key question is, to what extent does Tor open you up to MITM attacks?  I don't have a good feel for this. I read about exit nodes routinely doing very naughty things, but I don't know how widespread that is. Probably you're right that with random selection of exits you're not excessively likely to get MITMd.

How does Tor itself manage anti-sybil? I know they have the directory consensus and they measure nodes to ensure they're delivering the resources they claim to have. Punting anti-sybil up to the Tor people and letting them worry about it is quite an attractive idea.