06:56:36 <M5M400> hyc: i never doubted it was illicit. I just couldn't prove it. So I infiltrated, gathered info and relayed it to azure :)
06:58:25 <M5M400> 0|proxy  | 2020-06-09 17:04 +00:00: The proxy currently has 38385 miners connected at 201405703 h/s with an average diff of 78322
06:59:02 <M5M400> https://termbin.com/jir27
07:31:14 <sech1> M5M400 you got into the proxy? How?
07:59:54 <gethh> nice pick of the framework though
09:49:40 <M5M400> sech1: I asked for a root login. what else?
10:00:29 <sech1> How convenient :D
10:03:17 <M5M400> well he couldn't figure out how to install xnp himself so I offered
10:04:48 <M5M400> then gathered info and wiped it. he later built another one himself it seems
10:05:00 <M5M400> because it came back few hours later
14:34:10 <hyc> what a dolt
14:34:22 <hyc> glad you took care of the problem ;)
16:32:15 <lurkinandlearnin> there is a meeting about merge mining PoW in #tari
16:32:47 <hyc> and?
16:33:35 <hyc> the point of merge mining is any chain can merge mine with a parent chain without requiring any action on the parent chain's part
16:34:14 <lurkinandlearnin> it's an interesting discussion
16:34:39 <lurkinandlearnin> could a RandomX-type algorithm be created for GPUs? is that possible?
16:39:25 <selsta> no
16:41:16 <moneromooo> Yes. Though probably specific to one particular GPU architecture.
16:41:31 <hyc> anything that a highly parallel GPU can do well, an FPGA or ASIC can do better
16:41:33 <selsta> would that be randomx like then=
16:41:35 <selsta> ?*
16:42:08 <moneromooo> Fair point. I interpreted "RandomX-type" as "generate random instruction streams and hash the end state".
16:42:18 <moneromooo> But maybe that wasn't the intent :)
16:43:11 <moneromooo> Might be harder since you need to generate a state at the end, I'm not sure how much control you get over that.
16:43:16 <hyc> hmmm. well you may be right - you could probably tailor a randomx-like approach to a particular GPU family
16:43:53 <hyc> but AFAICS, "GPGPU" are not really very general purpose
16:44:02 <hyc> and generality is why RandomX works
16:47:14 <moneromooo> I'm not saying an ASIC could not get ahead, it might well be able to easier than for CPU. Just answering the question as is.
16:49:10 <hyc> yeah. there's another annoyance in that GPU instruction sets aren't publicly documented, and change dramatically from generation to generation
16:49:28 <hyc> so the JIT approach that makes RandomX fast on CPUs is much harder to develop for GPUs
16:51:41 <lurkinandlearnin> yeah I suppose "GPU" is too broad a target
16:52:04 <selsta> https://github.com/tevador/RandomX/blob/master/doc/design.md#randomx-design
16:52:12 <selsta> talks a bit on why CPU was chosen
17:10:18 <lurkinandlearnin> Oh yeah I understand why CPUs are a better option, I was just wondering whether something like RandomX could be created for other handware
17:10:39 <lurkinandlearnin> RISC-V could be a thing eventually
17:10:59 <hyc> RISC-V is just another CPU family, it will already work
17:11:18 <hyc> it's already supported by gcc; writing the JIT for it wouldn't be hard
17:14:12 <sech1> Isn't ProgPow "generate random instruction streams and hash the end state"?
17:25:45 <hyc> not very large or varied instruction streams
17:26:05 <hyc> leaves vast percentage of GPU silicon unused