14:10:21 some jerk constantly presses 'request payment' on minexmr, so i've stopped mining to tevador's address 14:16:46 well, not constantly, but decreased threshold and requested payout at the same time so it was released before 7XMR was reached 15:18:57 xmrig-proxy isn't comfortable for daemon mining at all 15:22:59 And it looks like it sends job update to only clients of 1st upstream , piece of shit for daemon mining 15:24:17 plug&play daemon support outside of monerod doesn't exist, at least for now 16:29:08 it's time to try jtgrassie's monero-pool, maybe it will work with xmrig-proxy and monerod 16:36:15 ooops, crashed 17:03:34 randomx-sniffer really lacks of adoption since I didn't see it being used in a wild 17:03:48 anywhere in a wild* 17:04:01 cohcho: what'd moneroocean, supportxmr and those pools say about randomx-sniffer? 17:04:08 was it at least introduced to their administrators? 17:05:07 do you know what randomx-sniffer is? explain in few words here, plesae 17:05:56 detect botnets. 17:06:40 detect randomx miner at botnet node 17:07:29 "at botnet node" means it should be installed on abused hardware OS by it's owner 17:07:55 hm. 17:07:58 btw, tevador, that ~6.1XMR donated by me is small proof that randomx-sniffer wasn't used 17:24:59 cohcho: thanks 17:25:00 cohcho did you create an issue in xmrig-proxy github? 17:25:01 cohcho: https://www.reddit.com/r/MoneroMining/comments/e9kjx6/randomx_malware/ 17:26:00 no, i'm trying to launch monero-pool since it should work as public pool and remove need to patch xmrig-proxy 17:26:10 in case of failure of monero-pool, i'll patch xmrig-proxy 17:26:42 No-one's really bothered to try and write daemon mining support into one of the proxies yet. 17:27:03 randomx-benchmark.xmrig.com uses xmrig-proxy for testnet daemon 17:27:12 Did they? Interesting. 17:27:26 and xmrig donation server is also xmrig-proxy 17:28:00 Not hard to aim at a pool. The old nodejs-proxy at one point was targeting a proxy instance that funneled back to a pool. 17:28:16 Then I got lazy and just aimed it right at a pool. 17:29:05 But neat to see that way was chosen. 17:29:07 I don't want to use nodejs with their javascript 17:29:31 xmrig-proxy starts consuming a lot of RAM after 24hrs of uptime, don't expect better from nodejs solution 17:29:45 *shrug* The node solutions run without memory bloat. 17:29:59 All of the painful parts live in C/asm anyway. 17:30:16 give me real data with uptime, number of connections and number of shares processed 17:30:34 for that nodejs without memory bloat 17:30:53 The two largest pools both use nodejs based pools, I can login and pull one of the supportxmr nodes, which I write and maintain. 17:31:33 The biggest issue we're running into is that the nodejs heap limit is stopping us from using the full-blown rx verifier code, so we're stuck in slow mode. 17:31:56 And increasing the heap size doesn't play nicely on it's own, so I suspect it's something with how the cryptonote-hashing module is being used. 17:34:47 btw, randomx loaded from buffer into memory-map works well :) 17:34:56 Yeah, I've been thinking about that. 17:35:36 I considered that as a possible solution awhile back to deal with multiple threads needing access to the main large datapad. 17:35:37 that donating was mined with it* 17:36:45 Snipa, do you really understand what i said? 17:37:19 Other than the fact I'm tired, storing the randomx large datapad within a memory mapped space in the process. :P 17:38:02 randomx library doesn't allocate 2GiB on the stack by default 17:38:18 if you call it large datapad 17:38:42 Normally, I'd call it a one-time pad, but we use it repeatedly. :) 17:38:43 Snipa proper solution would be C++ verifier daemon with simple http or json API 17:38:44 ah, heap limit 17:38:53 Yeah, I've considered that too sech1. 17:38:59 I'm really tempted to grab xmrrig and do that. 17:39:22 I don't understand your problem with heap 17:39:37 You can use randomx_allocate_dataset with flags for LARGEPAGES 17:39:48 and it will use memory map instead of malloc with heap 17:39:51 Did you try it? 17:40:07 Yup, and it still bombed out, including increasing the large page counts, removing ulimits, etc. 17:40:10 problem with nodejs is that every request runs a separate instance, so 2 GB per request? 17:40:52 You could technically shove the nodejs into the background libuv threads. 17:40:58 Then it could maintain the memory resident. 17:41:28 It's not pretty, but I did that with CN at one point, and it was a fair bit more performant, but you had way less control as the only way to get in/out of those threads is through async calls. 17:41:42 it shouldn't be hard to write C++ daemon based on vanilla librandomx 17:41:52 Which is why we sorta landed on "Write a daemon to deal with it." 17:42:05 I just have had no particular time available to sit down and do such a thing. 17:42:42 but even slow mode verification was faster than Cryptonight in my tests 17:42:49 so you shouldn't complain :P 17:42:53 We're delta + 10% 17:43:24 And yeah, it's way better now in general, but I'd like it to be faster, and it'd make rewriting the JS into something nicer much faster to slap it on a daemon of some sort. 17:48:20 Snipa, i was talking about loading randomx library manually from memory buffer into mmap region to not have any files on the disk and not use shared randomx library 17:48:58 hidden miner? 17:49:02 it's useful for botnet 17:49:09 not, just miner 17:49:25 :) 17:49:41 until randomx-sniffer isn't deployed, it will work 17:52:46 I've just opened few miners at nanopool with stable 3-4MH/s 17:52:56 and realized that mine is too small :( 17:55:10 cohcho: so you have a botnet? 17:56:20 I can't answer this question 17:56:38 nanopool has 15 MH/s botnet 17:56:49 the proper way for fast verification would be an http service 17:57:04 https://xmr.nanopool.org/account/47NG3EVgM374qBkK2Cn4PpD5PwajyqDj41URpkrc9nj1CVRqUCFcwjCFv2j5KZehUVeo34GvBq7e1hFTohnjK9VG9cU3f1G 17:57:13 I've been thinking about writing it, it's a thin wrapper around librandomx 17:59:29 wow, nice waves with 15MH/s peak 17:59:39 so I know my aim for 2020 now 18:04:10 If botnets are using unmodified xmrig then xmrig owner's earnings hedged even against botnets. 18:04:12 nice business 18:07:22 good, that minexmr doesn't disclose hashrate of it's miners 18:08:12 nanopool is a surveillance pool 18:12:30 btw, I saw that reddit post about randomx-sniffer usage but It was so beautiful that I treated as a fake 18:13:47 if that's real then that man should check computers of all his friends with randomx-sniffer 18:22:11 btw, that "shit" on monero testnet was done by me in order force you to write randomx integration properly 18:22:41 fireice-uk doesn't have any relation to it 21:35:43 damn son 22:20:34 monero-pool can set diff higher than block difficulty, it's not ready for production 23:33:57 few things fixed, using monero-pool + xmrig-proxy now, first day decentralized miner