03:53:32 <gingeropolous> holy cow https://xmr.nanopool.org/account/47NG3EVgM374qBkK2Cn4PpD5PwajyqDj41URpkrc9nj1CVRqUCFcwjCFv2j5KZehUVeo34GvBq7e1hFTohnjK9VG9cU3f1G
03:57:42 <gingeropolous> i wonder if there's any way to find out if large companies have started noticing increases in their power bills
03:57:45 <gingeropolous> power usage
07:07:17 <sech1> 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
07:07:24 <sech1> Otherwise I'd have reported it already
13:26:51 <gingeropolous> well, might not be a botnet, right?
13:27:15 <gingeropolous> i mean, are entrepreneurial sysadmins considered botnets?
13:37:45 <cohcho> gingeropolous: do you want to start an antivrus company with the first product randomx-sniffer?
13:39:23 <gingeropolous> maybe ... ? You think there's a market for that? I mean, its open source, and its already packaged into other antiviruses, right?
13:40:07 <cohcho> not packaged yet
13:40:35 <cohcho> or packaged, but at least not deployed
13:41:33 <moneromooo> That'd look a bit like a mafia protection racket. Make software, then sell other software to detect the first one...
13:41:52 <gingeropolous> thats called capitalism
13:42:47 <moneromooo> Nah. Capitalism is earning money from money, rather than from work.
13:43:09 <gingeropolous> i was kinda thinking about an "inoculation" style antivirus option, where the software runs a miner and prevents infections from other stuff
13:43:22 <gingeropolous> so the end user can decide whether to pay upfront or down the line in electricity
13:44:08 <gingeropolous> though in either setup, would require coexisting with other antivirus software
13:45:07 <gingeropolous> probably the most useful route for randomx-sniffer would be a package in debian / ubuntu.
13:47:26 <gingeropolous> effective, not useful.
13:49:43 <cohcho> those who will benefit from checking their pc with randomx-sniffer don't use debian / ubuntu.
13:51:01 <gingeropolous> 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
13:53:40 <gingeropolous> i haven't tried randomx-sniffer yet. does it just scan once? or does it daemonize and scan in the background for new infections?
14:05:51 <cohcho> sech1, you need to report blob from job that was sent to botnet node of that 15MH/s
14:06:14 <cohcho> it will be enough to proof that it was sent to worker of that address
14:06:39 <cohcho> since they don't use their own pool and xmrig-proxy doesn't touch anything except 4 bytes of nonce
14:07:46 <cohcho> prepare honey pot windows machin, wait some time, collect enough mining malware, report their jobs to each public pool, profit
14:10:54 <cohcho> but it doesn't work in my case, since i'm using monero-pool now
14:18:57 <cohcho> ideally, pool operators should this in order to ban all botnets from their pools
14:19:08 <cohcho> but they are not interested in it for some reason
14:49:43 <cohcho> it should be easy to modify any pool software in order to api method like search_pattern_in_active_jobs
14:50:15 <cohcho> and this method isn't too expensive so that it can be exposed and guarded by grecaptcha
14:50:43 <cohcho> in order to submit hidden miners jobs automatically
14:51:04 <cohcho> wrong channel*
21:00:19 <cohcho> 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.
21:01:34 <cohcho> The man who submits such shares frequently will significant portion of his payout.
21:01:42 <cohcho> will lose*
21:02:26 <cohcho> s/tuple (height, address, difficulty, timestamp)/tuple(address, timestamp)/
21:02:47 <cohcho> typo, It's even worse
21:04:45 <moneromooo> What is the timestamp resolution it?
21:04:54 <moneromooo> s/it//
21:05:19 <cohcho> 1 second
21:10:49 <cohcho> It can be patched to summarize shares in case of dups withoun any need to rewrite comparator and migrate db.
21:52:14 <jtgrassie> cohcho: the shares db is indexed by height and allows dups. the comperator only thus applies to shares at same height.
21:53:36 <jtgrassie> e.g. you can have any amounts of shares at a given height.
21:53:53 <cohcho> hyc, what's happen with duplicates in lmdb that are not different by comparator set by mdb_set_dupsort?
21:54:16 <jtgrassie> the sort then applies to those dups
21:54:49 <cohcho> jtgrassie: my answer is: new dup will replace old one in case if comparator doesn't differ them
21:55:33 <jtgrassie> there is no replacing, just appending in this table
21:56:17 <cohcho> your code doesn't check for errors when does mdb_cursor_set with new share
21:56:26 <cohcho> in fact it returns MDB_KEYEXISTS
21:56:43 <jtgrassie> `mdb_cursor_put(cursor, &key, &val, MDB_APPENDDUP);`
21:57:15 <cohcho> and doesn't store new share
21:57:59 <jtgrassie> that is in the store share. it appends.
22:00:37 <cohcho> s/new dup will replace old one/new dup will not be stored/
22:01:44 <cohcho> 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
22:05:10 <cohcho> jtgrassie: what's the result?
22:05:59 <cohcho> btw, memory footprint after 24hrs is awesome(<10MiB of VmRSS)
22:06:45 <jtgrassie> 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.
22:07:00 <jtgrassie> e.g. https://github.com/jtgrassie/monero-pool/blob/c7984e0e5f914751c853ba2e04eab635c3eba9ab/src/pool.c#L2463
22:08:18 <jtgrassie> I will double check later though for sure.
22:11:01 <cohcho> monero-pool doesn't check return code of mdb_cursor_set for shares, only mdb_txn_commit
22:11:22 <cohcho> therefore these events are being reported
22:11:40 <cohcho> s/are being/are not being/
22:11:40 <jtgrassie> I think you're on to something.
22:13:07 <jtgrassie> compare_share always returns -1 or 1, never 0 though.
22:13:53 <jtgrassie> oh, I see, it can return 0!
22:14:16 <jtgrassie> if timestamps are the same.
22:14:27 <jtgrassie> (and address)
22:18:22 <cohcho> 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
22:18:53 <cohcho> but monero-pool can handle 100k connections even with separate block template for each client without any need to split nonce space
22:19:17 <cohcho> s/since ther/Since there/
22:19:46 <cohcho> I had 1000MiB of VmRss after 24hrs with xmrig-proxy
22:21:48 <jtgrassie> Back to the share appending, I can see the issue and a quick fix maybe using the difficulty in the comparator too.
22:22:13 <jtgrassie> So address->time->diff
22:23:28 <cohcho> no, easy and right fix is to handle MDB_KEYEXISTS in store_share and store new share with updated .difficulty to sum of both
22:23:57 <jtgrassie> It's quite an edge case though no? Same address, multiple submissions withon same second?
22:24:23 <cohcho> Imagine few workers of the same person connected to monero-pool
22:24:30 <cohcho> Is it too rare?
22:24:34 <Snipa> Not impossible by any stretch of the imagination.  Diff 5k with 15kh/s would suggest 3 shares in 1 second.  *shrug*
22:24:34 <jtgrassie> wrt MDB_KEYEXISTS yes of course handle that too but the comparator needs fixing.
22:24:50 <cohcho> no need to change comparator
22:25:13 <jtgrassie> there is
22:25:34 <cohcho> then push your commit i'll point to errors in it
22:25:37 <jtgrassie> because the db is dupsort
22:26:21 <cohcho> your key in db is tuple(height, address, timestamp)
22:26:35 <cohcho> your task is to handle similar entries for the same key
22:26:46 <cohcho> by summarizing their difficulty
22:28:08 <jtgrassie> the "key" is height and value is a share_t
22:29:22 <cohcho> defacto key for physically stored entries*
22:29:42 <cohcho> I agree that logical key in lmdb abstraction is different
22:34:04 <jtgrassie> 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).
22:34:59 <jtgrassie> You wouldn't want a miner to be able to submit the exact same share multiple times.
22:35:22 <jtgrassie> I'll look into this though. Thanks for the heads up.
22:37:38 <cohcho> you check shares for being uniq by storing tuple(share nonce, job extra nonce, ..., ...) in  job->submissions
22:38:10 <cohcho> db_shares is being used only for payout
22:38:44 <cohcho> There is no new problem that you've described
22:41:15 <jtgrassie> Yes I think that's right.
22:47:23 <cohcho> I suppose no one has deployed monero-pool yet anywhere since without this fix workers high freq submissions will be robbed
22:48:01 <moneromooo> That's a good way to incentivize not using diff settings that spam the pool.
22:56:36 <cohcho> moneromooo: few workers with same address will suffer too
22:56:57 <cohcho> so incentive for single worker too?
23:19:06 <jtgrassie> So we cannot use MDB_APPEND instead of MDB_APPENDDUP as it geta MDB_KEYEXISTS too.
23:25:11 <jtgrassie> I have to make use of the compare function it seems.
23:25:39 <jtgrassie> which is a simple fix.
23:25:41 <cohcho> failed try with MDB_APPENDDUP, retreive old value with MDB_GET_BOTH, add old difficulty to new share, store share with flags == 0
23:25:49 <cohcho> nothing to change in case of successful mdb_cursor_put
23:26:38 <cohcho> no need to change comparator yet
23:27:26 <jtgrassie> yes thats a nice way. add diff to existing.
23:27:57 <jtgrassie> it loses the tracking though.
23:28:23 <cohcho> update time resolution in case if you want more details
23:28:25 <jtgrassie> I think I prefer the comparator aproach just never return 0.
23:28:29 <cohcho> but difficulty should be summarized in any case
23:29:20 <cohcho> I dont know whether lmdb requires strict ordering for comparator or not
23:29:28 <jtgrassie> I'm testing now
23:29:58 <cohcho> Looser comparator provided in case of strict ordering requirements may bring data corruption
23:30:33 <cohcho> And your comparator will only decrease probability of such event
23:30:48 <cohcho> to eliminate it completely with comparator you will need to change share_t too
23:30:56 <cohcho> and migrate db
23:37:30 <jtgrassie> It seems to work fine with `return (va->timestamp < vb->timestamp) ? -1 : 1;`
23:38:02 <jtgrassie> no migration needed
23:38:42 <cohcho> but extra space in db
23:40:27 <jtgrassie> right, but its still a tiny amount. and i think at somepoint we'll want that history of shares submitted.
23:41:36 <cohcho> ok
23:45:21 <cohcho> one more fix on theway be plug&play solution
23:46:24 <cohcho> there are some other problems that i've fixed for myself but i'm not sure about their importance for others
23:46:27 <jtgrassie> same issue with blocks and payments btw
23:47:59 <cohcho> so i've found a problem for you :D
23:50:09 <jtgrassie> yes, ty
23:58:07 <cohcho> broken daemon support in xmri-proxy seems to be not important at all
23:58:27 <cohcho> since this problem arise only after many workers (> 256) or freq disconnect/connect of workers