[Edes]

I don't think there's a trivial amount of computation people would want to perform that would cost too much for bots to advertise. I don't think people would be willing to wait 20 minutes on their phone to post a comment on a website. Assuming it's SHA256 like Bitcoin, from this video [1] a Samsung S22 Ultra does 400Kh/s. On a 6700 XT, the hashrate is 24 MH/s, that is like 50 times faster, or 24 seconds per post. If they use an ASIC it shoots up to the TH level. That's milliseconds. The service would need to be unusable on a phone unless people leased servers to validate their posts on, leading to costs for each post.

[1] https://youtu.be/iXMHKZGVZ0g

[mhink]

Hmm. I hadn't considered that. In my defense, I'm actually not a crypto guy at all, and so I hadn't given much thought to the actual dynamics. And now that I think about it, I don't think I've seen many relays actually implement that particular protocol extension, and this is probably why.

On the other hand, I think it's reasonable to note that individual relays could very well change their proof-of-work requirement over time to deal with network conditions. Because clients are expected to send events to as many relays as possible, it's not unreasonable to suppose that a client's message might very well make it through _somewhere_, even if a particular relay won't accept their message at a particular moment. Clients can always try again later.

I think it's also worth treating PoW as part of a "swiss cheese model" for managing abuse. There are layers in front of it (since the protocol uses WebSockets, all your standard DDOS protections can sit in front) as well as behind it (blacklisting or throttling pubkeys you don't know very well.)

One example that comes to mind is another protocol extension which provides a mechanism for client authentication, where a server can send a challenge string, in which case the client is expected to respond with a special event type which includes that same challenge string. Requiring a much higher proof-of-work requirement for this message type (and then accepting a lower PoW for messages sent afterwards on the same connection) is at least one idea of a scheme for mitigating spam.

---

For what it's worth, I wouldn't say I'm a True Believer at this stage of the game, but I find the whole thing pretty compelling, and at the very least it's something fun to hack on and experiment with.