Hi, Given the significant environmental impact of POW in other distributed systems (blockchain), we should not implement schemes that solve a problem for Tor but create problems for people elsewhere (potentially irreversible environmental damage).
https://www.theguardian.com/technology/2018/nov/05/energy-cost-of-mining-bitcoin-more-than-twice-that-of-copper-or-gold Other less-destructive schemes exist to prevent DoS attacks. POW is a method, not a goal in itself. Taking a step back and examining the full spectrum of available tools would be better. Chelsea On 2019-06-13 06:21, George Kadianakis wrote: > juanjo <jua...@avanix.es> writes: > >> Hello, this is my view of things, please be gentle as this is my first >> proposal draft :) >> > > Hello, > > thanks for working on this. IMO any proof-of-work introduction proposal > can be seen as orthogonal to David's prop305 which is a rate-limiting > proposal (even tho it's not named as such) and hence deserves its own > thread. > >> _ADAPTIVE POW PROPOSAL:_ >> >> Client sends the INTRODUCE1 as normal. >> >> Introduction Point checks the Current Requests Rate and checks the DoS >> settings. >> >> -DoS check is OK: send INTRODUCE2 to Hidden Service etc... >> > > So far so good (even tho this is not our usual proposal format). > >> -DoS settings/rate limit reached: then >> >> 1.Introduction Point generates a random 8 bytes key (IPKey) and >> associates it with the client circuit. Then send INTRODUCE_POW to the >> Client with the IPKey. > > Is this a new cell? What's the format? Are these really keys or are they > just nonces? > > IMO we should not do this through a new cell because that increases the > round-trip by one. Instead we should just embed the PoW parameters in > the onion service descriptor and clients find them there. > >> 2.Client computes POW. >> Do{ >> Generates random 8 bytes key (ClientKey). >> Generates hash(sha512/256 or sha3??) of >> hash(IPKey + ClientKey) >> } while (hash does not start with "abcde") >> > > That looks like a naive PoW scheme. It would perhaps be preferable to > try to find a GPU/ASIC-resistant or memory-hard PoW scheme here, to > minimize the advantage of adversaries with GPUs etc.? Are there any > good such schemes? > > Also services should definitely be able to configure the difficulty of > the PoW, and IMO this should again happen through the descriptor. > >> 3. Client sends INTRODUCE_POWR to the I.P. with the generated POW >> and the ClientKey. > > IMO this should happen as part of the INTRODUCE1 cell. > >> 4. I.P. checks the POW: >> >> -POW is correct: send INTRODUCE2 to HS. >> -POW is not correct: send INTRODUCE_POW_ERROR to client with >> new IPKey. >> >> *I say 8 bytes for the Keys just for example. >> >> PROS AND CONS, who needs to update Tor version?: >> -------------- >> >> Only rate limit: Introduction Point and Hidden Service. No breakage. >> >> POW: Client, Introduction Point and Hidden Service. POW will break >> compatibility with other v3 Hidden Services clients, if we implement a >> way to bypass POW for old clients then this feature won't work as intended. >> >> A forgotten guy here: Authenticated Rends cell: where we make sure the >> Client established a connection to the Rend Point before requesting the >> INTRODUCE1. >> > > Yep, that's yet another proposal (ticket #25066). > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev