Well, the attack is successful when they own the guard node, but becoming the guard node through random selection by the hidden service is what takes so long and costs so much money. Yep, that's basically what I was saying. Alternatively, if the hidden service operator didn't want to deal with anonymously purchasing extra servers for the entry guards, they could change the length of time that they keep entry guards: Change 30 to 180 and you've got entry guards for up to 6 months at a time, minus churn. Then it takes 4 years and $44,000 to achieve a 90% success rate with this attack. Adjust as needed. Are you talking about Tor over Tor, ie you run two Tor instances and proxy one instance (which serves the hidden service) through the SocksPort of the other? Because all hidden services work over Tor. In any case, I don't think Tor over Tor (or even layered entry guards) helps here, because the probability of the attacker becoming one of the first-layer entry guards is the same. That is more worrying. It looks like it's easy for an attacker to pull of, and there's not much a hidden service can do to defend against it. It's not like messing with your entry guards or intro points, because in order for your visitors to figure out your configuration in the first place (like which intro points they can talk to you), they need to find your descriptor. That requires mutual assumptions made by both parties: for example, that I as your visitor can find your hidden service descriptor at a relay whose fingerprint is closest to the hash of your public key and the date. They can make the descriptor ID unpredictable, for example by concatenating a random string to the hash of the public key and the date, and hashing that again, but that kind of solution needs to be implemented by the whole network, and new browser bundles must be distributed to users. They are working on it thought: https://trac.torproject.org/projects/tor/ticket/8244