I heard that one of the larger markets on tor is shutting down, due to an ongoing DDoS attack. They claimed that they had to pay off the attackers to stop the DDoS (extortion). From my basic normie understanding, the problem here is that it’s too cheap to do a DDoS on tor, so what I’m wondering is, if there’s a way to use grin as a value based network protocol layer, in that, all data transfer, all requests, pings, whatever, cost some amount of grin.
Let’s assume it is possible, we’ll pretend this network is called gTor. To a regular user, the cost of accessing/utilizing a gTor website would be minimal, almost nothing. But to someone trying to flood a website with requests, it would be incredibly expensive. Also, if this gTor thing were real, it would create a huge demand for grin.
So basically, I think the solution to the tor ddos problem, is a new network like tor, that monetizes all data transfer.
So my question is, is this possible, and is this possible to use grin to make this?
Another solution is to leverage PoW (don’t forget that the original reason Hashcash was created was to fight email spam).
Loki (a Monero fork) claims to use PoW for offline messaging and path creation.
Loki proposes a modified proof-of-work scheme to address the two largest Sybil attack sur-faces in the Loki system; offline messages and path creation. Offline messages present apotential target because each message must be stored by a swarm of nine nodes. Potentialabuse could arise where a malicious user overloads a particular swarm with a high volume of messages that it would have to store. In path creation attacks, the attacker seeks to engagein the path creation process with as many nodes as possible, taking up bandwidth resourcesand denying service to users who create paths through the network for legitimate purposes.
To prevent both attacks, the Loki network requires that a short proof-of-work be attachedwhen both messages and paths are created. For messages, this proof-of-work is calculatedas a Blake2b hash of the message. For path creation, the proof-of-work is sent along withthe request for a node to be included in the path building process. To ensure scalability andaccessibility for mobile users, the proof-of-work difficulty requirement is fixed based on theTime-to-live (TTL) of the message or the path, and not based on global network activity.