00:23:04 <M5M400> campuscodi40: what do you want to know?
01:54:49 <hyc> xmrpow: if pools responded with the equivalent of an HTTP 301 response code, and the mining clients remembered where they got redirected to
01:55:19 <hyc> essentially making pools load balance across all of themselves
01:57:53 <hyc> or maybe we just provide that as a service, just like moneroworld.com. point your miner at pool.moneroworld.com, get redirected to some low hashrate pool
02:01:14 <hv-bridge> <Donkeybrrrrrr> so many pool pages to have saved to monitor hash, what would happen if you hit a pool with unreliable backend, would the miner have to choose to take the fee hit to have a reliable pool?
02:36:17 <gingeropolous> .network
02:43:10 <gingeropolous> yah know, the random timelock block reward as being implemented in wownero could provide a network level way to make pool ops raise fees
02:43:56 <gingeropolous> due to miners probably wanting a steady stream of payout, pool ops would have to have some "savings" of monero to pay out at a steady pace
02:44:12 <gingeropolous> to ensure this savings exist, they could raise the pool fees
02:44:30 <gingeropolous> basically, the way to make pools have higher fees is to make it a pain in the ass to run pools
02:44:49 <gingeropolous> though that could also drive centralization as too few may run pools
02:49:52 <gingeropolous> however, because there is already a relatively healthy and strong pool network, it could drive distribution amongst the existing pool infrastructure
02:51:20 <gingeropolous> and in general it drives away opportunistic profiteers from mining and keeps the beliebers
02:54:47 <xmrpow> hyc: But then the person who owns pool.moneroworld.com has control over which small pools are going to be supported. In my opinion that is quite centralized.
02:55:10 <gingeropolous> yeah
02:56:30 <solar> M5M400: that guy from zdnet has a call w/ Microsoft tomorrow, which is why I told him to get in touch with you
02:56:38 <solar> might be worth trying to reach out to him again
02:57:00 <solar> possibly could get the message across to the correct people
02:59:50 <xmrpow> hyc: I think the way to go is with an economical incentive disincentive architecture.
06:15:18 <M5M400> solar: we talked.
06:16:03 <solar> with MSFT? or that guy
07:22:29 <sech1> I've analyzed extra nonces from that miner and the data suggests it's more like 10 kh/s per worker and ~80k workers. Still very approximate.
07:28:34 <sech1> the sheer count (80k) suggests it's not ASICs
07:44:31 <sech1> No, it looks like he runs 6 workers but only 4 different names, total number of workers behind them is ~130k
07:45:11 <sech1> which makes it ~7 kh/s per worker
07:48:18 <sech1> results of extra nonce analysis of 219 mined blocks: https://paste.debian.net/hidden/31c365d9/
07:48:58 <sech1> xnp assigns extra nonces to workers by increasing them by 1
07:49:14 <sech1> so it's straight-forward to figure out worker count, given enough blocks
11:59:05 <gingeropolous> awesome work sech1 . thanks
12:44:26 <UkoeHB_> kind of a sad testament to the transparency of mining atm...
12:48:24 <hyc> it would be trivial to write a miner or tweak an existing miner to change its nonce pattern
12:51:29 <moneromooo> And always use 0xA51Cxxxx to mess with people's heads.
12:57:16 <hyc> LOL
14:01:42 <sech1> hmm, the numbers don't really add up. All nonces from that miner are in the range 0 - 524287, and (nonce % 32768) is in the range 0 - 20000 only
14:02:13 <sech1> If it's xmrig then it's runs 16 threads, but each thread is so slow it can't count up to even 20000 during block time
14:02:50 <sech1> which means each worker is around 1 kh/s? But 130k workers and 900 MH/s means it should be 7 kh/s...
14:05:01 <sech1> or maybe xmr-node-proxy sends new jobs to workers quite often and they reset counters, I don't know
14:05:27 <Snipa> XNP uses what?  17 bytes worth of nonce?  As it's a pool level, a miner level, then the normal nonce miners increment.
14:05:46 <Snipa> I'd have to check, it's documented in the source somewhere, but I haven't looked at that code in forever.
14:05:55 <sech1> It's 16 bytes
14:06:06 <sech1> pool uses first 8 bytes, then XNP uses 4+4 bytes to split workers
14:06:42 <sech1> Snipa how often does proxy send new jobs? Only when pool sends a job?
14:06:49 <Snipa> Depends on the miner.
14:07:03 <Snipa> Pool will cause it to send, as well as miners able to request new job ID's.
14:07:32 <sech1> because if workers get new job every 30 seconds then it all adds up fine
14:08:09 <Snipa> Should be every 2 usually.
14:08:15 <Snipa> *2 mins.
14:11:18 <sech1> updateDifficulty is called every 45 seconds and it sends new job to workers almost all the time. Add new jobs from pool and it all adds up now
14:11:35 <sech1> Snipa you have to know your own code better :D
14:11:37 <Snipa> UD doesn't send that often if the miner's expected diff is within range.
14:12:29 <sech1> it doesn't send if calculated diff gets out of bounds (set in config)
14:12:53 <sech1> that miner probably cranked it up in config
14:13:56 <Snipa> Probally, no idea what their configs look like.
14:14:31 <Inge-> hashrate drop now? 22 blocks in 90 minutes
14:15:43 <sech1> you're probably on the wrong chain
14:15:49 <sech1> much more than 22, check xmrchain.net
14:16:02 <Inge-> ooh boy
14:19:56 <Inge-> oh that was some hours ago.
14:21:50 <sech1> damn, if proxy sends new jobs more often than pool jobs, it means my worker count estimate is incorrect
14:21:58 <sech1> each worker can be counted 2-3 times
14:23:06 <sech1> on the other side, pool can also be on vardiff and send new jobs often, so maybe it's correct after all
14:23:20 <Snipa> Pool lets the proxy have unlimited diff.
14:23:45 <Snipa> IIRC, it disables any fixed diff, though I'd have to check, because it's been forever.
14:23:46 <sech1> at least I can say "no more than 130k workers"
14:23:58 <sech1> but pool can also change diff for the proxy, right?
14:24:07 <sech1> diff for a share to be accepted
14:24:12 <Snipa> yes.
14:24:37 <sech1> so it's all vague now. It can be anywhere between 40k and 130k workers.
14:24:41 <Snipa> The proxy gets a few bypasses, but not a ton, it's still a miner, the STT of the proxy connection is 10 seconds, so the proxy should submit 3x as many shares as a normal miner.
18:27:14 <sech1> If anyone missed, this guy was on supportxmr chat today and said that he had 125k rigs for 1 month and paid for them
19:22:39 <Inge-> did he say ... *why*
19:39:39 <gingeropolous> its the most private way to obtain monero
19:43:27 <hyc> but it what 3:1 cost?
19:44:45 <gingeropolous> and did they provide evidence ?
19:45:38 <hyc> wouldn't providing evidence break their privacy?
19:46:27 <selsta> gingeropolous: evidence for what?
19:46:35 <selsta> that they have this much HR? yes
19:46:42 <gingeropolous> that the guy on supportxmr chat. .. oh
19:46:55 <gingeropolous> i mean, i could claim it was me and i had 600 rigs
19:47:20 <selsta> they renamed their workers as evidence
19:47:27 <gingeropolous> ah. there yah have it
19:47:57 <selsta> IP address is from Vietnam like the first Azure miner from a couple months ago, could be the same person
19:48:56 <gingeropolous> <endor00[m]> apparently he tried setting up his own pool multiple times but failed
19:49:02 <gingeropolous> from -pools
19:49:53 <gingeropolous> hrm, if indeed from vietnam, the 3:1 cost premium could be because thats the only way they can get monero
19:50:03 <gingeropolous> no idea what aml kyc or other hurdles are in place
19:50:13 <gingeropolous> but if you can get compute, you can get monteros!
19:50:27 <selsta> doubt it is a legit operation
19:51:10 <selsta> free credits / stolen accounts / credit cards most likely
22:26:02 <hyc> Ogawd, these people have no brains. "working on an application that would distribute work to user’s phones to create a mining pool for Monero. Right now I’m thinking of having our node do all of the RandomX proof of work steps up to generating the machine code which it would then send each phone its own random program to run. "
22:26:46 <hyc> sending ~4KB of machine code to every phone for every nonce, what kind of network bandwidth do they think they have?
22:26:59 <hyc> what kind of hashrate do they think they can get doing such stupid work
22:27:43 <hyc> I wish I had a proof-of-IQ on my email acct before anyone can email me