Measured: why the hardest challenge runs at a few bits and the cheap one needs 26
A new guide measures the two work functions behind browser proof-of-work challenges in the same WebAssembly runtime a browser uses. One SHA-256 probe costs 0.3997 microseconds; one Argon2id probe at 32 MiB costs 154.6 milliseconds - a ratio of about 387,000 to one. That inverts the difficulty settings: a memory-hard tier runs at a handful of bits where the compute tier needs 20 or more, and pushing the compute tier to 26 bits costs a real user a measured median of 19.1 seconds, with a worst run of 64.4 while a rented GPU farm barely notices. A 12-minute flood on 7 August, 67,751 challenges to 923 addresses across 525 networks in 97 countries, produced zero incorrect proofs - and the article is explicit that this shows nobody attempted the work, not that nobody could. Updated 9 August: a fleet of native solvers now answers what the flood could not - a botnet can earn about 0.6 tokens per second per core at four bits, costing it roughly 16 times our verification cost. Two corrections are published with it: one separating the derived compute figures from the measured memory-hard ones, and one retracting the claim that memory-hardness taxes an attacker's parallelism, which measurement reversed. A second flood on 9 August, 1.18 million requests in twenty-four minutes, reproduced the result on three times the scale: 2,036 challenges issued to the swarm and not one attempted, with the machine at a load average of 1.31 on four cores and DNS still answering in 25 to 43 milliseconds. Updated 11 August: the benchmark scripts are published at github.com/Ozy-666/dns-pow-bench with the raw output of four measurement passes. Repeating the run put real error bars on it - the four-bit solve median moved by 69 per cent across three passes of the same measurement, while the per-probe costs that carry the argument reproduced within 2.7 per cent.