19:54:57 <m-relay> <k​4r4b3y:karapara.net> Interesting commentary by java i2p router developer zzz on RandomX, Equi-X, Hash-X: http://zzz.i2p/topics/3624-tor-part-2-bananas-pow
19:57:42 <m-relay> <k​4r4b3y:karapara.net> >But the bananas part is that the hash function is a program. If you have a different seed, it's a different program.
20:02:23 <m-relay> <k​4r4b3y:karapara.net> >So you have the seed, you create the program. Fine. But then HashX compiles the program into amd64 or arm64 executable. Because if you're competing for a PoW reward, you want to be as fast as possible, right? So if you're implementing this in C, you "compile/assemble" your program into actual native instructions in a memory region, mark the region as executable, and jump to it. A<clipped message>
20:02:23 <m-relay> <k​4r4b3y:karapara.net> KA self-modifying (or maybe just self-generating) code. Does it work? yes. Is it secure? yes. Is it great optics for the premier security project to be doing self-modifying code for an undocumented, unaudited hash algorithm? Maybe not.
20:07:35 <m-relay> <k​4r4b3y:karapara.net> zzz's java port of eqiux: https://github.com/zzzi2p/jequix
20:14:33 <m-relay> <k​4r4b3y:karapara.net> >So, could we do this in i2p? Maybe? [...] There's other GPU-resistant hashing functions out there, basically ones that use a lot of memory. Maybe we could use one of them, I don't know. But I don't think Equi-X is for us. And would we really need GPU/ASIC resistance? How far would we be willing to go?
20:38:19 <sech1> yes, it's hard to implement JIT compiler in Java, so it will be very slow for them
20:40:58 <m-relay> <k​4r4b3y:karapara.net> What about Rust? Tor daemon is moving into rust, with the upcoming Arti daemon. Is it going to keep using the C-implementation of Equi-X?
20:41:44 <sech1> They'll just call the C function in an unsafe code block