holy cow xmr.nanopool.org/account/47NG3EVgM3…KZehUVeo34GvBq7e1hFTohnjK9VG9cU3f1G

i wonder if there's any way to find out if large companies have started noticing increases in their power bills

power usage

gingeropolous this botnet has been around for ages and they do things "properly" i.e. they hide mining address on the mining machines (possible with proxy), so this address hasn't surfaced anywhere but this IRC :D

Otherwise I'd have reported it already

well, might not be a botnet, right?

i mean, are entrepreneurial sysadmins considered botnets?

gingeropolous: do you want to start an antivrus company with the first product randomx-sniffer?

maybe ... ? You think there's a market for that? I mean, its open source, and its already packaged into other antiviruses, right?

not packaged yet

or packaged, but at least not deployed

That'd look a bit like a mafia protection racket. Make software, then sell other software to detect the first one...

thats called capitalism

Nah. Capitalism is earning money from money, rather than from work.

i was kinda thinking about an "inoculation" style antivirus option, where the software runs a miner and prevents infections from other stuff

so the end user can decide whether to pay upfront or down the line in electricity

though in either setup, would require coexisting with other antivirus software

probably the most useful route for randomx-sniffer would be a package in debian / ubuntu.

effective, not useful.

those who will benefit from checking their pc with randomx-sniffer don't use debian / ubuntu.

right. I don't know the makeup of botnets, but im guessing a large % are like me in my early days of fiddling with this stuff, where i didn't even put fail2ban on the servers i propped up

i haven't tried randomx-sniffer yet. does it just scan once? or does it daemonize and scan in the background for new infections?

sech1, you need to report blob from job that was sent to botnet node of that 15MH/s

it will be enough to proof that it was sent to worker of that address

since they don't use their own pool and xmrig-proxy doesn't touch anything except 4 bytes of nonce

prepare honey pot windows machin, wait some time, collect enough mining malware, report their jobs to each public pool, profit

but it doesn't work in my case, since i'm using monero-pool now

ideally, pool operators should this in order to ban all botnets from their pools

but they are not interested in it for some reason

it should be easy to modify any pool software in order to api method like search_pattern_in_active_jobs

and this method isn't too expensive so that it can be exposed and guarded by grecaptcha

in order to submit hidden miners jobs automatically

wrong channel*

jtgrassie: comparator for share_t used in lmdb doesn't differ shares with the same tuple (height, address, difficulty, timestamp) that are possible and not rare.

The man who submits such shares frequently will significant portion of his payout.

will lose*

s/tuple (height, address, difficulty, timestamp)/tuple(address, timestamp)/

typo, It's even worse

What is the timestamp resolution it?

s/it//

1 second

It can be patched to summarize shares in case of dups withoun any need to rewrite comparator and migrate db.

cohcho: the shares db is indexed by height and allows dups. the comperator only thus applies to shares at same height.

e.g. you can have any amounts of shares at a given height.

hyc, what's happen with duplicates in lmdb that are not different by comparator set by mdb_set_dupsort?

the sort then applies to those dups

jtgrassie: my answer is: new dup will replace old one in case if comparator doesn't differ them

there is no replacing, just appending in this table

your code doesn't check for errors when does mdb_cursor_set with new share

in fact it returns MDB_KEYEXISTS

`mdb_cursor_put(cursor, &key, &val, MDB_APPENDDUP);`

and doesn't store new share

that is in the store share. it appends.

s/new dup will replace old one/new dup will not be stored/

make small test, clean lmdb db, start testnet pool, connect xmrig to its with small diff, wait for at least 2 submits, wait until pool initilize randomx dataset and start processing of those 2 shares at the sime second, check db content

jtgrassie: what's the result?

btw, memory footprint after 24hrs is awesome(<10MiB of VmRSS)

I dont have time this second to test right now but I neved noticed failed appends before, and there are even logs which would catch a failed transaction for storeing a share.

e.g. github.com/jtgrassie/monero-pool/bl…2e04eab635c3eba9ab/src/pool.c#L2463

I will double check later though for sure.

monero-pool doesn't check return code of mdb_cursor_set for shares, only mdb_txn_commit

therefore these events are being reported

s/are being/are not being/

I think you're on to something.

compare_share always returns -1 or 1, never 0 though.

oh, I see, it can return 0!

if timestamps are the same.

(and address)

sinse ther are some memory leaks in xmrig-proxy or fragmented heap after malloc/free It doesn't really a solution to handle 100k connections on a cheap vps

but monero-pool can handle 100k connections even with separate block template for each client without any need to split nonce space

s/since ther/Since there/

I had 1000MiB of VmRss after 24hrs with xmrig-proxy

Back to the share appending, I can see the issue and a quick fix maybe using the difficulty in the comparator too.

So address->time->diff

no, easy and right fix is to handle MDB_KEYEXISTS in store_share and store new share with updated .difficulty to sum of both

It's quite an edge case though no? Same address, multiple submissions withon same second?

Imagine few workers of the same person connected to monero-pool

Is it too rare?

Not impossible by any stretch of the imagination. Diff 5k with 15kh/s would suggest 3 shares in 1 second. *shrug*

wrt MDB_KEYEXISTS yes of course handle that too but the comparator needs fixing.

no need to change comparator

there is

then push your commit i'll point to errors in it

because the db is dupsort

your key in db is tuple(height, address, timestamp)

your task is to handle similar entries for the same key

by summarizing their difficulty

the "key" is height and value is a share_t

defacto key for physically stored entries*

I agree that logical key in lmdb abstraction is different

the problem arises with multiple shares for same address in same second. I could just append (eg MDB_APPEND instead of MDB_APPENDDUP) but then there could be an integrity issue (eg each miner submitted share must be unique).

You wouldn't want a miner to be able to submit the exact same share multiple times.

I'll look into this though. Thanks for the heads up.

you check shares for being uniq by storing tuple(share nonce, job extra nonce, ..., ...) in job->submissions

db_shares is being used only for payout

There is no new problem that you've described

Yes I think that's right.

I suppose no one has deployed monero-pool yet anywhere since without this fix workers high freq submissions will be robbed

That's a good way to incentivize not using diff settings that spam the pool.

moneromooo: few workers with same address will suffer too

so incentive for single worker too?

So we cannot use MDB_APPEND instead of MDB_APPENDDUP as it geta MDB_KEYEXISTS too.

I have to make use of the compare function it seems.

which is a simple fix.

failed try with MDB_APPENDDUP, retreive old value with MDB_GET_BOTH, add old difficulty to new share, store share with flags == 0

nothing to change in case of successful mdb_cursor_put

no need to change comparator yet

yes thats a nice way. add diff to existing.

it loses the tracking though.

update time resolution in case if you want more details

I think I prefer the comparator aproach just never return 0.

but difficulty should be summarized in any case

I dont know whether lmdb requires strict ordering for comparator or not

I'm testing now

Looser comparator provided in case of strict ordering requirements may bring data corruption

And your comparator will only decrease probability of such event

to eliminate it completely with comparator you will need to change share_t too

and migrate db

It seems to work fine with `return (va->timestamp < vb->timestamp) ? -1 : 1;`

no migration needed

but extra space in db

right, but its still a tiny amount. and i think at somepoint we'll want that history of shares submitted.

ok

one more fix on theway be plug&play solution

there are some other problems that i've fixed for myself but i'm not sure about their importance for others

same issue with blocks and payments btw

so i've found a problem for you :D

yes, ty

broken daemon support in xmri-proxy seems to be not important at all

since this problem arise only after many workers (> 256) or freq disconnect/connect of workers