[tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

[johnymnx at airmail.cc]

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