4 ms·
> 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
by geocar 3mo ago
> 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 https://news.ycombinator.com/item?id=30175269
- swinglock 3mo agoCan 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.
- deleted 3mo ago[deleted]
- geocar 3mo ago> 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 3mo agoIf it takes seconds to compile it then the browser wins. The PoW only runs for seconds already.
- geocar 3mo agoNo 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.
- dorgo 3mo ago[flagged]