14:29:35 on verification, parallelize in second thread 14:30:47 on additional algorithm, there's no mathematical proof another algorithm is impossible 17:33:39 parallelism is already being used *now* 17:35:53 you can't hide the slowdown 17:36:31 as for mathematical proof of other algorithm - it's actually pretty simple 17:36:45 any fixed algorithm can be optimized by a fixed-function ASIC 17:37:04 therefore the only possible way to defeat ASICs is with a dynamic algorithm 17:37:28 if the algorithm is sufficiently dynamic, it will be equivalent to RandomX 17:52:19 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 18:00:31 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 18:01:15 It's all deterministic, or it couldn't be used as PoW 18:02:53 "Predictable" means predictable by CPU branch predictor 18:02:59 so branches that follow some pattern 18:06:13 so it'd be good to have predictable branches to waste less energy, right? 18:07:28 no 18:07:29 then comes the problem with the pattern. No matter where it comes from, ASIC can just use it and predict 100% 18:07:45 ^ 18:10:02 would overwriting binary code at runtime break the pattern? 18:14:44 overwriting it with what? 18:15:09 what are you going to put in there that an ASIC developer can't also use to their advantage? 18:16:35 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". 18:16:45 perfect 18:22:18 with code that changes the branch pattern 18:22:45 my previous question still stands 18:34:58 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 18:43:10 meanwhile, "Miners 39038" 18:43:26 it's been growing fast in the recent few days 18:53:20 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 18:59:30 maybe with indirect branches 19:19:15 the pattern must be implemented in code. the code can be embedded into ASIC. 19:19:48 you're handwaving your way thru stuff that just won't work. 19:22:25 its a tempting thing so thats for sure 19:26:55 why isn't the register controlling the branch never modified? 19:28:07 double negative 19:33:30 because if it's modified, we can't guarantee that the program always finishes 19:49:30 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 19:50:23 no. 19:50:35 we did that in an earlier version 19:50:48 you're just retreading old ground that's not worth doing 19:52:35 adding a check will itself perturb the branch predictor 19:52:43 it adds a great deal of overhead 21:07:35 which areas of RandomX need improvement? 21:26:41 it would help if what you tried was documented somewhere 21:27:02 did you try stopping the program with the global debug registers