on verification, parallelize in second thread

on additional algorithm, there's no mathematical proof another algorithm is impossible

parallelism is already being used *now*

you can't hide the slowdown

as for mathematical proof of other algorithm - it's actually pretty simple

any fixed algorithm can be optimized by a fixed-function ASIC

therefore the only possible way to defeat ASICs is with a dynamic algorithm

if the algorithm is sufficiently dynamic, it will be equivalent to RandomX

RandomX is not perfect too, it doesn't have nested loops and conditional branches (except for regular loops). RandomX VM is Turing complete most probably though

on "Fully predictable branches cannot depend on the runtime value of any VM register". I think this means deterministic, not fully predictable. A value can be unpredictable until runtime but deterministic

It's all deterministic, or it couldn't be used as PoW

"Predictable" means predictable by CPU branch predictor

so branches that follow some pattern

so it'd be good to have predictable branches to waste less energy, right?

no

then comes the problem with the pattern. No matter where it comes from, ASIC can just use it and predict 100%

^

would overwriting binary code at runtime break the pattern?

overwriting it with what?

what are you going to put in there that an ASIC developer can't also use to their advantage?

You put a text string that reads "by reading this text you agree not to use an ASIC to mine monero. If you do not agree, do not read this text".

perfect

with code that changes the branch pattern

my previous question still stands

I think creating branch patterns which are predictable and at the same time can't be cheated with look-up table is a topic for many future PhD thesises

meanwhile, "Miners 39038"

it's been growing fast in the recent few days

not sure: something that flips the branch direction from one to the other, in a way that expands exponentially the number of possible states the ASIC would have to cache

maybe with indirect branches

the pattern must be implemented in code. the code can be embedded into ASIC.

you're handwaving your way thru stuff that just won't work.

its a tempting thing so thats for sure

why isn't the register controlling the branch never modified?

double negative

because if it's modified, we can't guarantee that the program always finishes

can something be added that guarantees the problem always finishes? like add in every basic block a different type of branch that checks if the program should be aborted after a lot of basic blocks were executed

no.

we did that in an earlier version

you're just retreading old ground that's not worth doing

adding a check will itself perturb the branch predictor

it adds a great deal of overhead

which areas of RandomX need improvement?

it would help if what you tried was documented somewhere

did you try stopping the program with the global debug registers