juanjo juanjo@avanix.es writes:
Ok, thanks, I was actually thinking about PoW on the Introduction Point itself, but it would need to add a round trip, like some sort of "authentication based PoW" before allowing to send the INTRODUCE1 cell. At least it would make the overhead of clients higher than I.P. as the clients would need to compute the PoW function and the I.P. only to verify it. So if right now the cost of the attack is "low" we can add an overhead of +10 to the client and only +2 to the I.P. (for example) and the hidden service doesn't need to do anything.
Also see the idea in (b) (1) here: https://lists.torproject.org/pipermail/tor-dev/2019-April/013790.html and how it couples with the "rendezvous approver" from ticket #16059. Given a generic system there, adding proof-of-work is a possibility.
Another option would be to add the proof-of-work in the public parts of INTRO1 and have the introduction point verify it which is not covered in our email above.
Proof-of-work systems could be something to consider, altho tweaking a proof-of-work system that would deny attackers and still allow normal clients to visit it (without e.g. burning the battery of mobile clients) is an open problem AFAIK.