Can a simple sequential delay function leave little room for FPGA acceleration?

Sorry my post yesterday didn't explain the goal clearly. The discussion ended up going in the wrong direction because of a casual hypothetical use case I mentioned, while what I'm actually trying to build is a **time-lock encryption** tool: once a message is encrypted, it should only become decryptable after some amount of time has passed, similar in spirit to the classic [Time-Lock Puzzles](https://people.csail.mit.edu/rivest/pubs/RSW96.pdf).

Of course, in theory a VDF would be the cleanest way to do this. But I'm currently experimenting with a different approach: **encryption costs about as much total work as decryption**, but [the encryption side can be parallelized on the GPU](https://github.com/EtherDream/timelock/raw/main/docs/images/encryption.webp). Right now, on a high-end GPU, a few seconds of encryption can produce roughly a day of decryption time.

I'm mainly exploring two things here:

1. **How far browser optimization can be pushed** — i.e. whether a browser implementation can get close to native speed for this kind of sequential computation.

2. **Whether the function leaves relatively little room for hardware acceleration**, especially on FPGAs (since those are much more accessible than ASICs).

Because I'm not aiming for a VDF here, the algorithm itself can stay pretty simple. I tried both 32-bit and 64-bit versions. The core loops look like this (full details are in the [docs](https://github.com/EtherDream/timelock#-the-slow_hash)):

```c
// 32-bit
for (int i = 0; i < n; i++) {
a *= 0x85EBCA6B; b ^= a;
b *= 0xC2B2AE35; a ^= b;
// ...
}

// 64-bit
for (int i = 0; i < n; i++) {
x *= 0xD1342543DE82EF95;
x ^= x >> 32;
// ...
}
```

These loops run almost entirely in registers, with no memory traffic in the hot path, so they avoid a lot of the sandbox overhead that memory-heavy designs would have in the browser. In my tests, the browser version reaches about **~99% of native performance**.
Live demo (64-bit version): https://jsbin.com/qopokozuqu/edit?html,output

----

For resisting hardware acceleration, the usual approaches are things like **memory-hard functions** or **randomized programs**. Right now I'm looking more at the second option.

I didn't go with memory-hardness mainly for two reasons:

- In the browser, memory access adds more overhead. If browsers had something like built-in Argon2, that would be much more attractive.

- There's also a fairness issue: if the memory requirement is too large, some users get excluded; if it's too small, it becomes easier to accelerate. Some high-end CPUs already have L3 caches 1GB+.

Because the algorithm is so simple (no big integers, etc.), the amount of speedup available on FPGA seems pretty limited, at least for a **single sequential decryption task**. It may even have trouble beating a high-clock CPU. Sure, an ASIC could probably get a bigger speedup, but most people are not going to fabricate a chip just to break a multi-day time-lock.

At this point I feel like the two experimental goals have mostly been achieved. What I'm still worried about is whether the algorithm is **too simple**: it's basically just MUL+XOR, and I don't know if that leaves some shortcut.

I've talked about it with a few crypto hobbyists and so far nobody has found an obvious shortcut, but that's exactly why I'm asking here: I'd like feedback specifically on the **sequential hardness** of this construction.