11:51:59 samholmes: It sounds like you need a VDF rather than a PoW function. 16:13:13 Damn, I found a bug in RandomX JIT for ARM and RISC-V that happens with 2^-28 probability (1 in ~268 million hashes). Considering that we have 1691193 RandomX blocks so far, the probability of it triggering (and making ARM/RISC-V nodes split) so far is... 0.628%... But it probably hasn't triggered yet because we didn't hear any reports of 16:13:13 ARM/RISC-V nodes failing to sync 16:13:36 selsta ^ 16:13:48 I'll prepare a patch until the end of the week 16:28:41 I think it should be fixable with a patch. Presumably, the majority of miners are on x86, so their chain would win in case of a fork. 16:30:20 yes, it can go into the next point release 16:31:07 The RISC-V JIT was tested just with 10M hashes and that ran for 2 days IIRC 16:35:01 yeah 16:35:09 needed to test with 1 billion hashes :D 16:36:44 I'll probably also make a generator that finds a failing hash (should be ~1 minute to find on 9950X with VAES-512 and scanning for the first of the 8 programs) 17:28:51 tevador I don't know if I have the permissions, but can you create a "v1.x" branch on from 102f8ac commit (1.2.1 tag) in RandomX repo? 17:41:14 Done: https://github.com/tevador/RandomX/tree/v1.x 18:41:36 > samholmes: It sounds like you need a VDF rather than a PoW function. 18:41:36 The intent is to use RandomX as a VDF because it is ASIC resistant or more specifically CPU bound. If you know of VDFs that use an algorithm that is leveled with consumer grade CPUs, then I'm all ears. Any brute-force attack would have to acquire hardware that the owner of the commitment would have fair advantage towards. In o [... too long, see https://mrelay.p2pool.observer/e/9OSRk4ELZ0ZGalhZ ] 19:28:42 yep, bug confirmed - I brute-forced and found one failing hash, and both ARM and RISC-V JIT compilers fail on that hash. 19:29:25 ugh. good catch 19:42:31 https://github.com/tevador/RandomX/pull/325 19:46:20 I'll make another PR for master branch tomorrow