some jerk constantly presses 'request payment' on minexmr, so i've stopped mining to tevador's address

well, not constantly, but decreased threshold and requested payout at the same time so it was released before 7XMR was reached

xmrig-proxy isn't comfortable for daemon mining at all

And it looks like it sends job update to only clients of 1st upstream , piece of shit for daemon mining

plug&play daemon support outside of monerod doesn't exist, at least for now

it's time to try jtgrassie's monero-pool, maybe it will work with xmrig-proxy and monerod

ooops, crashed

randomx-sniffer really lacks of adoption since I didn't see it being used in a wild

anywhere in a wild*

cohcho: what'd moneroocean, supportxmr and those pools say about randomx-sniffer?

was it at least introduced to their administrators?

do you know what randomx-sniffer is? explain in few words here, plesae

detect botnets.

detect randomx miner at botnet node

"at botnet node" means it should be installed on abused hardware OS by it's owner

hm.

btw, tevador, that ~6.1XMR donated by me is small proof that randomx-sniffer wasn't used

cohcho: thanks

cohcho did you create an issue in xmrig-proxy github?

cohcho: reddit.com/r/MoneroMining/comments/e9kjx6/randomx_malware

no, i'm trying to launch monero-pool since it should work as public pool and remove need to patch xmrig-proxy

in case of failure of monero-pool, i'll patch xmrig-proxy

No-one's really bothered to try and write daemon mining support into one of the proxies yet.

randomx-benchmark.xmrig.com uses xmrig-proxy for testnet daemon

Did they? Interesting.

and xmrig donation server is also xmrig-proxy

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.

Then I got lazy and just aimed it right at a pool.

But neat to see that way was chosen.

I don't want to use nodejs with their javascript

xmrig-proxy starts consuming a lot of RAM after 24hrs of uptime, don't expect better from nodejs solution

*shrug* The node solutions run without memory bloat.

All of the painful parts live in C/asm anyway.

give me real data with uptime, number of connections and number of shares processed

for that nodejs without memory bloat

The two largest pools both use nodejs based pools, I can login and pull one of the supportxmr nodes, which I write and maintain.

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.

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.

btw, randomx loaded from buffer into memory-map works well :)

Yeah, I've been thinking about that.

I considered that as a possible solution awhile back to deal with multiple threads needing access to the main large datapad.

that donating was mined with it*

Snipa, do you really understand what i said?

Other than the fact I'm tired, storing the randomx large datapad within a memory mapped space in the process. :P

randomx library doesn't allocate 2GiB on the stack by default

if you call it large datapad

Normally, I'd call it a one-time pad, but we use it repeatedly. :)

Snipa proper solution would be C++ verifier daemon with simple http or json API

ah, heap limit

Yeah, I've considered that too sech1.

I'm really tempted to grab xmrrig and do that.

I don't understand your problem with heap

You can use randomx_allocate_dataset with flags for LARGEPAGES

and it will use memory map instead of malloc with heap

Did you try it?

Yup, and it still bombed out, including increasing the large page counts, removing ulimits, etc.

problem with nodejs is that every request runs a separate instance, so 2 GB per request?

You could technically shove the nodejs into the background libuv threads.

Then it could maintain the memory resident.

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.

it shouldn't be hard to write C++ daemon based on vanilla librandomx

Which is why we sorta landed on "Write a daemon to deal with it."

I just have had no particular time available to sit down and do such a thing.

but even slow mode verification was faster than Cryptonight in my tests

so you shouldn't complain :P

We're delta + 10%

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.

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

hidden miner?

it's useful for botnet

not, just miner

:)

until randomx-sniffer isn't deployed, it will work

I've just opened few miners at nanopool with stable 3-4MH/s

and realized that mine is too small :(

cohcho: so you have a botnet?

I can't answer this question

nanopool has 15 MH/s botnet

the proper way for fast verification would be an http service

I've been thinking about writing it, it's a thin wrapper around librandomx

wow, nice waves with 15MH/s peak

so I know my aim for 2020 now

If botnets are using unmodified xmrig then xmrig owner's earnings hedged even against botnets.

nice business

good, that minexmr doesn't disclose hashrate of it's miners

nanopool is a surveillance pool

btw, I saw that reddit post about randomx-sniffer usage but It was so beautiful that I treated as a fake

if that's real then that man should check computers of all his friends with randomx-sniffer

btw, that "shit" on monero testnet was done by me in order force you to write randomx integration properly

fireice-uk doesn't have any relation to it

damn son

monero-pool can set diff higher than block difficulty, it's not ready for production

few things fixed, using monero-pool + xmrig-proxy now, first day decentralized miner