05:53:32 <cohcho> First successful response from pool operator who found address of hidden miner proxy by job
05:57:47 <cohcho> It has few MH/s now and earned 100XMR so far
05:59:26 <cohcho> only 21 days old
13:53:52 <koe> do miners updated the hashing blob when new transactions are discovered?
13:54:40 <cohcho> No,True for all pools listed at miningpoolstats.stream at least within first 2 minutes
13:54:57 <cohcho> Then it varies, but most still don't update on tx
13:55:15 <cohcho> Some states that has custom trigger for reward change (not single new tx)
13:56:16 <koe> Isthmus ^
14:01:23 <koe> Since minimum fees per block are less than 1USD within the penalty free zone, that isn't significant for miner income. It is significant for fingerprinting mining software.
15:25:17 <cohcho> I have potentially bad news
15:26:58 <gingeropolous> whats that
15:28:05 <gingeropolous> the anticipation is killing me
15:28:08 <moneromooo> That's things you did not know of before which are going to disappoint you, but let's not get sidetracked...
15:30:00 <gingeropolous> i guess i'll have to guess then
15:32:38 <gingeropolous> cohcho, im on the edge of my keyboard!
15:33:02 <gingeropolous> and highly caffeinated!
15:35:38 <fort3hlulz> Us waiting for cohcho https://media.tenor.com/images/bd527ed7a4220b9a7b34e14ab5c3771b/tenor.gif
17:33:48 <cohcho> It's related to rx_slow_hash and affects only those who call rx_slow_hash with miners != 0 and has rx_dataset == nullptr (lack of memory or MONERO_RANDOMX_MASK = 4).
17:34:18 <cohcho> Validation in monerod isn't affected.
17:34:28 <cohcho> http://paste.debian.net/plainh/5d35ec7b
17:34:53 <cohcho> patch to fix probably the last problem with randomx integration
17:35:04 <Isthmus> Ooh interesting, thanks for looping me in @koe
17:35:44 <cohcho> monero-pool launched with MONERO_RANDOMX_MASK=4 rejected 40 minutes of my valid hashrate
17:35:58 <cohcho> someone reported problems in monero-pool with share validations by supportxmr.com
17:36:35 <cohcho> s/monero-pool with//
17:45:38 <cohcho> pop blocks to have ( height % 2048 < 63), launch MONERO_RANDOMX_MASK=4 monerod --fixed-difficulty=256 (something bigger than 1 to not accept random PoW and to have small diff) , start mining
17:58:09 <tevador> btw, i7-9850H (laptop CPU) = 3500 H/s, not bad
18:00:50 <tevador> let's see if the laptop doesn't burn if I let it mine for a couple days
18:07:35 <cohcho> How are you running i7-9850H within a laptop?
18:07:47 <cohcho> Is it 100% frequency + turbo?
18:08:25 <cohcho> (laptop CPU) <- within laptop or not?
18:09:37 <tevador> it's in a laptop (Dell)
18:10:37 <tevador> base frequency is 2.6 GHz, but it mines at around 3.2 GHz
18:11:27 <tevador> cohcho: btw I'm pretty sure the flag is MONERO_RANDOMX_UMASK
18:11:44 <tevador> and: https://github.com/monero-project/monero/blob/master/src/crypto/rx-slow-hash.c#L244-L246
18:12:46 <cohcho> yes, UMASK
18:12:52 <cohcho> I didn't copy/paste from terminal
18:12:59 <cohcho> typo
18:13:36 <cohcho> What did you mean with 'and ...'?
18:14:35 <cohcho> That code will not be used in that rare case since rx_vm != NULL
18:14:35 <tevador> it will set miners to 0
18:14:48 <cohcho> Try to ren mining as I've described
18:15:01 <cohcho> It's just 3 blocks
18:15:08 <cohcho> to run*
18:16:12 <cohcho> That problem has not been added/fixed by your commit
18:16:27 <tevador> a better fix would be to set miners to 0 if dataset allocation fails
18:17:06 <cohcho> "a better fix" write commit, paste it somewhere and i'll tell what's wrong
18:18:11 <tevador> soon (tm)
18:18:16 <cohcho> Do you know what are we going to do with identified botnets?
18:19:19 <cohcho> We will have for sure lower boundary of their hashrate and reward
18:19:58 <tevador> you can't block botnets, they will just run their own solomining pool
18:20:17 <tevador> the only solution is for people to fix their broken PCs
18:20:25 <tevador> *patch
18:20:38 <cohcho> It's possible to obtain list of their victims and send randomx-sniffer to them probably
18:20:41 <cohcho> somehow
18:21:08 <tevador> how do you obtain a list of victims?
18:21:27 <cohcho> at least IPs
18:21:50 <tevador> IP of the first NAT
18:22:05 <cohcho> But in case of NAT it may take much time to deanonymize real pc
18:22:07 <tevador> welcome to the world of obsolete IPv4
18:22:10 <cohcho> Yes, the first NAT
18:23:50 <cohcho> I have plan how to ban them on regular basis in case of working honeypot  and some small support from pools
18:24:07 <cohcho> s/ban them/identify their wallet at pool/
18:24:33 <tevador> it would work just on low effort botnets mining on public pools
18:24:40 <cohcho> And the only way to avoid that detection is to do solo mining
18:24:45 <tevador> and only if pool operators cooperate
18:25:05 <cohcho> There is simple api that should be implemented
18:25:12 <cohcho> after that it will be fully automatic
18:25:56 <cohcho> admin of one pool implemented it within 1 day
18:26:10 <tevador> but it's not a bad idea to automatically ban addresses if someone submits a valid job for it
18:26:18 <tevador> that's a pretty good evidence
18:26:33 <cohcho> of course, since no one legitimate miner will post his job on twitter
18:27:00 <tevador> and people mining over plain http deserve to get banned
18:27:05 <cohcho> 32 bytes at the of job blob is 100% evidence of miner
18:27:25 <cohcho> with honeypot + randomx sniffer + some manual investigation for each new sample
18:27:39 <cohcho> They can use any form of sophisticated obfuscation to hide real ttraffic
18:27:49 <cohcho> The only we need is to find input to randomx_calculate_hash
18:28:39 <tevador> the result would be that botnets would move to private pools or pool that don't implement this new API
18:28:41 <cohcho> pool.find_wallet_by_blob_tx(input[-32:]) == hidden_miner_wallet
18:28:56 <cohcho> Yes, and we will see them as unknown part
18:29:00 <cohcho> all of them
18:29:21 <cohcho> even self-select will not help them
18:29:24 <cohcho> only solo mining
18:29:39 <cohcho> or protection from pool operator that share their earnings
18:32:02 <sech1> solo-mining botnets everywhere... real decentralization!
18:33:12 <cohcho> It's better to wrap randomx-sniffer into something final, because of every miner or interested in monero human should check pc of his friends with randomx-sniffer.
18:33:30 <cohcho> It's easy and probably works if there is no way to bypass it.
18:33:48 <cohcho> trend-micro is sleeping for some reason
18:34:38 <tevador> look, if people just updated their windows to 1909 and enabled windows security, there would be hardly any botnets left
18:35:33 <cohcho> Sometimes you need to download untrusted but free software
18:35:55 <cohcho> and protection with false positives will be disabled in that case
18:36:01 <tevador> aaaand that's how you get malware
18:36:03 <cohcho> good scanning tool is much better that protection
18:36:52 <cohcho> I've lost all my malware since I'm not using windows any more and don't play games.
18:43:05 <cohcho> I'm excited to finally get hashrate lower boundary of active randomx botnets.
18:43:30 <tevador> probably way less than everyone thinks
18:44:43 <sech1> the largest botnet I know of is 15 MH/s
18:46:52 <cohcho> I remember
18:47:16 <sech1> https://xmr.nanopool.org/account/47NG3EVgM374qBkK2Cn4PpD5PwajyqDj41URpkrc9nj1CVRqUCFcwjCFv2j5KZehUVeo34GvBq7e1hFTohnjK9VG9cU3f1G
18:47:18 <cohcho> tevador: It would be good evidence of decentralization in case of true
18:47:30 <cohcho> And of centrelazition in case of false
18:48:08 <cohcho> centralization*
19:42:20 <cohcho> jtgrassie: can you write few words about that monero-pool PR: not needed, pending, poorly written?
20:17:31 <koe> there may be risk of botnet-friendly pools becoming active
21:00:14 <jtgrassie> cohcho: which PR?
21:00:38 <cohcho> at jtgrassie/monero-pool
21:01:40 <cohcho> koe: It depends on the power of those who want to identify botnets. There are some heuristics and ways to obtain proof that concrete pool hides botnets.
21:01:42 <jtgrassie> you mean #31
21:01:59 <cohcho> You can create phony botnet attach to pool and ask it's owner to provide address.
21:02:13 <cohcho> In case of reject you have 100% evidence.
21:02:36 <cohcho> yes
21:02:45 <koe> what can you do if there is such a pool though?
21:03:35 <cohcho> I suppose the same approach as for suspending virtual machine rented for malicious activity.
21:03:50 <jtgrassie> #31 so a round is a little misleading in so far as you are counting all shares since last found block
21:03:53 <cohcho> At least complete pool can be marked 100% botnet
21:04:23 <cohcho> Yes, all shares with timestamp more than timestamp of the last found block.
21:05:08 <jtgrassie> right, but that doesn't mean they will all be paid out, hence why "round" maybe misleading.
21:05:45 <jtgrassie> also, you don't need to MDB_PREV_DUP, just start at last and MDB_PREV.
21:06:06 <cohcho> The definition of round should include all shares between found blocks. Do you have better name?
21:06:40 <jtgrassie> but thats not quite how PPLNS calculates a round
21:07:20 <cohcho> I've done test few days ago and MDB_PREV_DUP was required to count all shares even those with equal timestamp. I'll repeat it one more time.
21:08:11 <cohcho> This statistic is mainly to track current progress in block mining. Not reward distribution
21:08:28 <jtgrassie> yeah that's what I assumed.
21:08:57 <jtgrassie> Its not a biggie, just "round" can be misleading if thinking in payout terms.
21:09:43 <cohcho> Also for PPLNS shares should be iterated in reverse timestamp order, not height order. But in general on mainnet you will not have rare alt chains that shorter but heavier
21:10:32 <cohcho> s/round/estimate of hashes computed by workers since last found block/
21:10:46 <cohcho> I don't know short term that match it
21:11:39 <cohcho> There is also small typo s/startup_pauout/startup_payout/
21:13:24 <jtgrassie> height is fine for payouts
21:14:07 <cohcho> always or mostly?
21:14:27 <cohcho> or from your point of you?
21:14:32 <jtgrassie> haha
21:18:12 <jtgrassie> generally you will pay out all shares at height -2. sure there will be straglers, so you're probably right to factor the timestamp
21:20:16 <jtgrassie> if we were to use timestamp a migration would be wise to use ts as key maybe
21:20:37 <cohcho> Yes, that change will require migration
21:21:07 <cohcho> Also db size could be descreased with separate mapping (address -> id) in order to not store 128bytes with each share
21:21:47 <jtgrassie> yeah there's a couple of places it could be reduced.
21:21:56 <cohcho> Since my pc isn't very stable I've added mdb_sync_database after store of share, block and payment
21:22:10 <cohcho> But it's very specific to my environment
21:22:48 <jtgrassie> I have a local branch with some migration utils so just a case of time
21:24:31 <jtgrassie> on payouts, it already should factor in timestamp because although the SET is on height, the order of DUPS factor in timestamp
21:24:39 <jtgrassie> (or used to anyway)
21:26:33 <jtgrassie> Thus I would use the same loop logc for your "round" calculation. e.g. Use SET on height, loop back to last found block height.
21:30:44 <jtgrassie> But as you round code currently is is also fine, just would change to go from LAST looping PREV till last mined block time.
21:43:31 <cohcho> till means include shares with timestamp > or >= ?
23:57:22 <jtgrassie> >
23:58:39 <jtgrassie> and MDB_LAST, MDB_PREV works fine.