← Back to context

Comment by dspillett

9 hours ago

> It also means that the "hey Claude vibeslop me a CUDA Anubis solver" route is on its way to being fundamentally dead.

I assume that the previous challenges will still be available for circumstances where WASM is not available (unless we are just working on the basis that it is available if JS is?) or perhaps as a fallback. TFA explicitly mentions “smart” TVs, and I'm sure there are plenty of those out there that run browsers old enough to not know what WASM is. TBH these would not be a priority for me, but they obviously are for this project given they (well, TVs generally, not specifically elderly ones) get specific mention in this write-up.

If so, what is to stop scrapers from just forcing the fallback POW option instead of trying to run the new memory-hard algorithm at all?

5 comments

dspillett

Reply
Lyrex  8 hours ago

the answer to this is in the post: where wasm is not available, he transpiles the wasm binary back to Javascript

  • dspillett  7 hours ago

    Ah I must have skipped by that bit. And presumably the memory-hard algorithm is CPU-easy enough that this won't be a problem. That leaves me wondering "why not just use a JS memory-hard routine in the first place, but maybe I've shouted over that too. I'll give TFA a reread later.

    • trickypr  6 hours ago

      I think it is still compute-heavy if not compute-hard, and stuff like WASM SIMD makes it less compute heavy (not really available in JS). And also, for memory bound problems, you probably don't want the JS GC needing to clean up afterwards when WASM gives you that control.

      1 reply →