First successful response from pool operator who found address of hidden miner proxy by job

It has few MH/s now and earned 100XMR so far

only 21 days old

do miners updated the hashing blob when new transactions are discovered?

No,True for all pools listed at miningpoolstats.stream at least within first 2 minutes

Then it varies, but most still don't update on tx

Some states that has custom trigger for reward change (not single new tx)

Isthmus ^

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.

I have potentially bad news

whats that

the anticipation is killing me

That's things you did not know of before which are going to disappoint you, but let's not get sidetracked...

i guess i'll have to guess then

cohcho, im on the edge of my keyboard!

and highly caffeinated!

Us waiting for cohcho media.tenor.com/images/bd527ed7a4220b9a7b34e14ab5c3771b/tenor.gif

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).

Validation in monerod isn't affected.

patch to fix probably the last problem with randomx integration

Ooh interesting, thanks for looping me in @koe

monero-pool launched with MONERO_RANDOMX_MASK=4 rejected 40 minutes of my valid hashrate

someone reported problems in monero-pool with share validations by supportxmr.com

s/monero-pool with//

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

btw, i7-9850H (laptop CPU) = 3500 H/s, not bad

let's see if the laptop doesn't burn if I let it mine for a couple days

How are you running i7-9850H within a laptop?

Is it 100% frequency + turbo?

(laptop CPU) <- within laptop or not?

it's in a laptop (Dell)

base frequency is 2.6 GHz, but it mines at around 3.2 GHz

cohcho: btw I'm pretty sure the flag is MONERO_RANDOMX_UMASK

and: github.com/monero-project/monero/bl…src/crypto/rx-slow-hash.c#L244-L246

yes, UMASK

I didn't copy/paste from terminal

typo

What did you mean with 'and ...'?

That code will not be used in that rare case since rx_vm != NULL

it will set miners to 0

Try to ren mining as I've described

It's just 3 blocks

to run*

That problem has not been added/fixed by your commit

a better fix would be to set miners to 0 if dataset allocation fails

"a better fix" write commit, paste it somewhere and i'll tell what's wrong

soon (tm)

Do you know what are we going to do with identified botnets?

We will have for sure lower boundary of their hashrate and reward

you can't block botnets, they will just run their own solomining pool

the only solution is for people to fix their broken PCs

*patch

It's possible to obtain list of their victims and send randomx-sniffer to them probably

somehow

how do you obtain a list of victims?

at least IPs

IP of the first NAT

But in case of NAT it may take much time to deanonymize real pc

welcome to the world of obsolete IPv4

Yes, the first NAT

I have plan how to ban them on regular basis in case of working honeypot and some small support from pools

s/ban them/identify their wallet at pool/

it would work just on low effort botnets mining on public pools

And the only way to avoid that detection is to do solo mining

and only if pool operators cooperate

There is simple api that should be implemented

after that it will be fully automatic

admin of one pool implemented it within 1 day

but it's not a bad idea to automatically ban addresses if someone submits a valid job for it

that's a pretty good evidence

of course, since no one legitimate miner will post his job on twitter

and people mining over plain http deserve to get banned

32 bytes at the of job blob is 100% evidence of miner

with honeypot + randomx sniffer + some manual investigation for each new sample

They can use any form of sophisticated obfuscation to hide real ttraffic

The only we need is to find input to randomx_calculate_hash

the result would be that botnets would move to private pools or pool that don't implement this new API

pool.find_wallet_by_blob_tx(input[-32:]) == hidden_miner_wallet

Yes, and we will see them as unknown part

all of them

even self-select will not help them

only solo mining

or protection from pool operator that share their earnings

solo-mining botnets everywhere... real decentralization!

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.

It's easy and probably works if there is no way to bypass it.

trend-micro is sleeping for some reason

look, if people just updated their windows to 1909 and enabled windows security, there would be hardly any botnets left

Sometimes you need to download untrusted but free software

and protection with false positives will be disabled in that case

aaaand that's how you get malware

good scanning tool is much better that protection

I've lost all my malware since I'm not using windows any more and don't play games.

I'm excited to finally get hashrate lower boundary of active randomx botnets.

probably way less than everyone thinks

the largest botnet I know of is 15 MH/s

I remember

tevador: It would be good evidence of decentralization in case of true

And of centrelazition in case of false

centralization*

jtgrassie: can you write few words about that monero-pool PR: not needed, pending, poorly written?

there may be risk of botnet-friendly pools becoming active

cohcho: which PR?

at jtgrassie/monero-pool

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.

you mean #31

You can create phony botnet attach to pool and ask it's owner to provide address.

In case of reject you have 100% evidence.

yes

what can you do if there is such a pool though?

I suppose the same approach as for suspending virtual machine rented for malicious activity.

#31 so a round is a little misleading in so far as you are counting all shares since last found block

At least complete pool can be marked 100% botnet

Yes, all shares with timestamp more than timestamp of the last found block.

right, but that doesn't mean they will all be paid out, hence why "round" maybe misleading.

also, you don't need to MDB_PREV_DUP, just start at last and MDB_PREV.

The definition of round should include all shares between found blocks. Do you have better name?

but thats not quite how PPLNS calculates a round

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.

This statistic is mainly to track current progress in block mining. Not reward distribution

yeah that's what I assumed.

Its not a biggie, just "round" can be misleading if thinking in payout terms.

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

s/round/estimate of hashes computed by workers since last found block/

I don't know short term that match it

There is also small typo s/startup_pauout/startup_payout/

height is fine for payouts

always or mostly?

or from your point of you?

haha

generally you will pay out all shares at height -2. sure there will be straglers, so you're probably right to factor the timestamp

if we were to use timestamp a migration would be wise to use ts as key maybe

Yes, that change will require migration

Also db size could be descreased with separate mapping (address -> id) in order to not store 128bytes with each share

yeah there's a couple of places it could be reduced.

Since my pc isn't very stable I've added mdb_sync_database after store of share, block and payment

But it's very specific to my environment

I have a local branch with some migration utils so just a case of time

on payouts, it already should factor in timestamp because although the SET is on height, the order of DUPS factor in timestamp

(or used to anyway)

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.

But as you round code currently is is also fine, just would change to go from LAST looping PREV till last mined block time.

till means include shares with timestamp > or >= ?

>

and MDB_LAST, MDB_PREV works fine.