Hello, list ! Some ideas about this proposal, it's a little bit surface ideas, cause I'm not currently digging deep into the internals of Tor-core.

There's user division on different classes there ("The standard web user", "The motivated user", "The mobile user"). I would add "Registered user", user registered within the service. Thus service keeps fast-access DB(Redis) with some unique-id of registered user, which is given to registered user. When user wants to connect to HS, he puts this Unique-ID via TBB (similar to stealth auth introduced recently)

About "The mobile user", mobile user can be offered two options: 1. Go to Desktop 2. Compute series of reCAPTCHA 3. If mobile user is "The registered user", enter unique-id saved in some encrypted vault on the phone

Registered and unregistered class of users introduces another issue When HS starts its operation and no registered users exist, and DDoS starts with initial HS availability to the World, unregistered/guest users will have no chance to register on HS. Thus, hybrid solution is required, as described in 5.2 (5.2. Future directions [FUTURE_WORK]) "PoW + "Third-party anonymous credentials" HS must have Third-Party Human Puzzle service behind Anit-DDOS operator (Cloudflare, e.t.c.), where unregistered users could solve some AI-proof puzzles and get access-token to connect to HS

In the long run, when user base of HS is saturated, and number of user registrations decays, PoW for unregistered users can be significantly increased, thus protecting HS from huge DDoS attacks, cause it's usually when HS is popular and has big and saturated user base, it becomes target for huge DDoS attacks.

Verification of PoW I didn't dig deep to HS implementation, but it seems reasonable if decision about PoW verification is made on the closest node to client(ClosestNode).

1. HS sends encrypted PoW task to client 2. Client computes PoW 3. Client sends PoW to ClosestNode 4. ClosestNode verifies PoW (verification of PoW is always much faster, than Proof) 5. Verification succeeded - approve connection to HS 6. Verification failed - disconnect this client

Finally, our proposal has a big benefit over the blockchain use cases: it's much more agile. We can deploy changes to the PoW algorithm without having to hard-fork, and we can do this even through the consensus for maximum agility. This means that we should try to use this agility to our advantage.

Change of PoW algorithms can be made in form of some PoW CAP(capability) flag, so some version of client supports PoW_CAP1, PoW_CAP2, PoW_CAP3 and HS supports PoW_CAP1, PoW_CAP1, thus they both can only interact with intersection of their PoW_CAP# sets. Similar to OpenVPN crypto-capabilities exchange between client and server