[geocar]

> but PoW scales

Not if the honest party is doing it in a browser: The same computer can so any POW so much faster in C than any amount jf JS and WASM that it will never ever ever be a contest.

> becoming much more obvious and easy to block, or they have to use massive amounts of compute.

If you believe this, please contact me: I think compute is free[1] and can probably help you out.

[1]: https://news.ycombinator.com/item?id=30175269

[swinglock]

Can you not design a PoW that is most efficient in a browser? Don't brute force hashes like Hashcash/Bitcoin, do something similar to RandomX instead but in JS. Browsers ought to run the fastest JS interpreters already so if interpreting JS becomes the bulk of the work, that attack might not work. Maybe even involve the DOM or whatever else makes sense.

[geocar]

> Browsers ought to run the fastest JS interpreters already

Well they don't.

Users want the website to work sooner, and care little about whether a for-loop of elements take 10ms or 20ms if it only happens once.

JS can be AOT compiled if you can wait a few _seconds_ -- which users don't want, so browsers don't bother.

Our attacker however, rightly observes they only have to pay that compilation cost once.

[swinglock]

If it takes seconds to compile it then the browser wins. The PoW only runs for seconds already.

[geocar]

No no no. You don’t realise the compiled intermediate can be _trivially_ reused for every request, and identified by the hash of the JavaScript code. Browsers already do this, it’s just your attacker has a bigger cache, and not by a little bit.

Browsers _intentionally_ limit the amount of memory and cpu cycles a tab can consume to make for a nicer human experience.