Thread by @bramcohen

Some thoughts on RandomX. The audits are more useful than the docs on this one (thread) github.com/tevador/Random…

Oddly the pop writeups babble on about virtual machines and such instead of straightforwardly saying it's based off Argon2. That's something which one should be proud of instead of obfuscating.

From the audits it's clear it went about how you'd expect. Some people with more CPU than cryptography experience took Argon2d and applied mixing functions which are reasonably spread out across the functionality on a standard CPU

Then it got audited and there was a bunch of feedback about how the mixing could in principle hit edge cases with undefined or underspecified behavior and in places could lose entropy, so they iterated and fixed that up until there wasn't much more to find

This is about as good of a methodology as you can follow for making an asic resistant proof of work function and if I were tasked with that problem I'd do something very similar

Whether the result is truly asic resistant is unclear. When 'asic resistant' proofs of work fail they fail hard because one manufacturer can easily beat everybody else and the budget for catching up to them is massive

So almost by definition the closer it comes to working the harder it fails when it does. Certainly if anyone does manage to make an asic for it they'll keep their mouths shut for fear of the proof of work algorithm getting hard forked out

Which leads to it being very unclear whether someone has built an asic already. If mining on general purpose CPUs was/is prohibitively expensive then that's a strong hint, but that's only likely to happen if there are two asic manufacturers duking it out, not just one

Looking into how it all plays out it's striking how similar the terminal condition of asic-friendly proofs of work and (successful) asic-resistant proofs of work is. Mining rigs aren't going to use standard desktop computers, they're custom setups which are racked \

in locations with cheap power and good heat dissipation and the like and lack things like hard drives and (in this case) GPUs. In some sense it's trying to be asic-friendly, it's just that one component of the 'asic' is a standard issue CPU

I of course would rather go completely thermonuclear and switch to proofs of space, which is exactly what we're doing at Chia.

A funny side note: The class group operations used in Chia VDFs turn out to be fairly asic-resistant, at least if you've got fancy IFMA. But that of course fails at the goal of using the whole chip and being perfectly optimized for by the latest generation of them

That of course is a moving target with the designs of chips and their instruction sets changing over time. But given the life of X86 its likely to be 'reasonably' stable for a while.