02:23:14 <needmonero90> How many CPUs can we estimate as being on the network atm?
02:23:19 <needmonero90> I think its 50k minimum
02:23:38 <needmonero90> And that's assuming 15kh/s for every CPU and 750mh nethash
02:23:57 <needmonero90> So that's like, about as firm a floor as you can get
02:27:11 <nioc> 15kh/s is more than a 3900X
02:33:09 <needmonero90> I'm upper bounding everything
02:33:19 <needmonero90> I thought I heard of someone getting 16kh
02:33:25 <needmonero90> From one chip
02:33:28 * needmonero90 shrugs
02:33:38 <needmonero90> What should the floor be? Give me a better estimate
02:33:50 <needmonero90> My numbers lowball everything hard
02:46:32 <nioc> 16k was a 3950X, my i3 with 1 stick of DDR3 gets 600 H/s
02:46:34 <nioc> I can't give you a better estimate but I am sure others will be able :)
02:57:18 <hyc> maybe take a 3600X benchmark as typical instead
02:57:28 <hyc> it seems to be the sweet spot in price/perf
02:57:49 <hyc> but of course, majority of CPUs are older than Ryzen 3000 generation
02:58:42 * moneromooo waiting for AMD to start mining with Ryzen 4000s before shipping them to customers
03:00:40 <hyc> lol. they could try, but the info would leak out pretty quickly
03:08:29 <gingeropolous> https://miningpoolstats.stream/monero
03:08:45 <gingeropolous> im trying to keep my eye on the # of miners in the 5th column
03:09:09 <gingeropolous> for all of bitcoins centralization, the # of miners is impressive
03:10:16 <nioc> does # of miners = # of addresses?
03:10:49 <gingeropolous> thats the best way I can think of that they do it
03:11:44 <nioc> so 25098 * X
03:12:08 <gingeropolous> but i dunno. maybe the pool's API provides different information on the actual # of workers
06:35:14 <tevador> looks like we've had a successful epoch change
06:38:28 <tevador> I'm pretty sure the network has >100k CPUs, probably even >200k
09:41:09 <Inge-> gingeropolous: Speaking of murmuring, Genesis Mining murmurs: "as the “RandomX” fork is also weakening general GPU mining capabilities considerably, there is no business-centric argument at this point, that can convince large-scale mining operations to try and adapt to these changing protocol rules without the need of large additional investments into any mining infrastructure for this
09:41:15 <Inge-> cryptocurrency. "
09:42:38 <Inge-> and "we cannot continue to offer Monero mining as a product any longer." Boo-fucking-hoo
11:56:39 <defterade_> Bitcoin has ~75x amount of miners (according to miningpoolstats.stream), but ~160x security budget compared to XMR
11:57:22 <defterade_> Interested to see what happens after the halvening
12:04:04 <hyc> security budget?
12:04:45 <ferretinjapan> security budget = block reward?
12:04:53 <defterade_>  + fees
12:04:59 <ferretinjapan> ^
14:18:35 <sech1> Interesting: https://www.techpowerup.com/261760/aws-starts-designing-32-core-arm-neoverse-n1-cpu-for-data-center
14:21:11 <sech1> Current CPU has 105W TDP, 64 cores @ 3.1 GHz and they're developing new 32 core version as far as I understood
14:56:35 <Inge-> defterade_: so it will be on par come May 2020 almost.
14:56:52 <Inge-> err nevermind. mind fog today
17:35:50 <tevador> Re: the risk of supercomputer-based 51% attack on Monero
17:36:08 <tevador> Summit (#1), Tianhe-2 (#4) and Frontera (#5) can do at most 300 MH/s each. Sierra (#2) is weaker than Summit. Not sure about Sunway TaihuLight (#3) - it has a custom CPU: https://en.wikipedia.org/wiki/Sunway_SW26010 but it looks to be similar to Xeon Phi, which doesn't seem to perform very well.
17:36:30 <tevador> so it looks like at least 3 TOP 5 supercomputers are needed to attack Monero at the moment.
17:39:28 <kinghat> since they were talking about a manufacturer attack and trying to use sales numbers to figure it out, it would be interesting to find its way less profitable to mine with the CPU inventory than to sell them
17:42:23 <tevador> it is way more profitable to sell, even for Epyc CPUs
17:43:05 <tevador> Epyc 7742 costs $7k and makes $160 per month of mining (before electricity costs)
18:42:56 <Inge-> no threadripper benchmarks yet? Any guesses?
19:21:55 <hyc> this guy may post some TR benches soon https://www.reddit.com/r/Amd/comments/dz60c5/a_linux_performance_look_at_amds_16core_ryzen_9/f86l2c8/
19:40:03 <p3rL> why this happend  any idea
19:40:06 <p3rL> [2019-12-03 11:53:19.219]  rx   failed to allocate RandomX dataset, switching to slow mode (6 ms)
19:40:06 <p3rL> Segmentation fault
19:40:59 <tevador> unstable CPU
19:41:12 <tevador> slow mode puts much higher load on the core
19:41:12 <p3rL> oki
19:41:27 <tevador> so the CPU may be stable in fast mode, but will crash in slow mode
19:41:56 <p3rL> its specially for few cpus ?
19:42:15 <p3rL> cause other works fine in slow mode
19:45:12 <tevador> depends on silicon lottery
19:49:15 <gingeropolous> is there any sense whatsoever in this "cryptonight adaptive" algorithm? https://bitcointalk.org/index.php?topic=3464367.0
19:49:42 <gingeropolous> seeing claims of pooled mining resistance always excites me... and then i get disappointed
19:50:33 <sech1> Angrywasp is... interesting person (not like FUK, but still interesting)
19:50:43 <sech1> He spent lots of time implementing what he claims
19:50:46 <sech1> So maybe it's true
19:51:15 <sech1> You need to store the whole blockchain to be able to mine it, hence "pool resistant"
19:51:17 <sech1> no idea why
19:51:39 <needmonero90> Probably uses random access to the chain data
19:51:44 <needmonero90> As part of the PoW
19:52:22 <gingeropolous> " Create a hash algorithm that changes automatically at regular intervals each time breaking support in ASICS, mining pools and GPU mining software".. that doesn't sound like it would break pooled mining
19:52:34 <gingeropolous> but thats oldschool needmonero90 , boolberry had that afaik
19:53:01 <moneromooo> Boolberry read from the chain. I want to say 2 GB of it but I could be wrong.
19:53:44 <sech1> Boolberry had something around 400 MB of data extracted from the chain
19:53:50 <sech1> before they switched to something else
19:55:07 <gingeropolous> and you can still read from a blockchain and have pooled mining. just increases the operational costs of mining.
19:55:48 <sech1> Pool verification server also needs full blockchain, maybe this is why
19:59:05 <gingeropolous> wat? pools need full blockchain regardless, right?
19:59:16 <gingeropolous> here's the commit for that algo apparently. https://bitbucket.org/nerva-project/nerva/commits/8079d37ebefd123381895da1de10d25467386339
20:03:40 <gingeropolous> i mean, i guess if you can force reading from the blockchain, you can force cooperative mining as opposed to hashing
20:04:17 <gingeropolous> so your still pooling, but your creating your own block templates
20:06:51 <gingeropolous> this could be the thing that gets jtgrassie's stratum thing to be enforcable
20:07:17 <sech1> The only way to prevent pool mining is to embed proof of knowledge into PoW proof
20:07:30 <gingeropolous> well, there's nuance with pooled mining
20:07:32 <sech1> aka miner must prove it know private spend keey for the wallet it mines to
20:07:58 <sech1> so it makes it literally impossible to mine to pool's wallet because everyone will have access to it
20:08:04 <gingeropolous> pooled mining with distributed creation of block template is relatively OK - the miners are creating the blocks, and are in a cooperative agreement.
20:08:08 <moneromooo> One coin did this. Called Pebblecoin I think ?
20:08:21 <moneromooo> Maybe another. But one definitely did.
20:08:21 <gingeropolous> no, it was something else. i remember it too
20:08:58 <gingeropolous> pooled mining with centralized block template creation is bad - this is what we have now, and miners are just workers
20:09:29 <sech1> XMRig supports stratum self-select btw
20:09:39 <Inge-> < sech1> You need to store the whole blockchain to be able to mine it <--- Sounds a bit like Arweave. But the Arweave implementation is not pool resistant as far as I can tell.
20:09:53 <moneromooo> I used to dislike pools but tbh I've kinda gone back a bit on that. Small pools are good, they allow low hash rate people to mine where they otherwise would not. Large pools are bad. But a large pool can masquerade as several small ones, so you can't attack large ones only. Unless a way is found...
20:09:58 <sech1> so we only need self-select pools now
20:09:59 <gingeropolous> spreadcoin
20:10:02 <Inge-> even if it is "proof of access" where you need a random previous block in order to mine this block
20:10:10 <moneromooo> Oooh, could well be gingeropolous.
20:10:42 <gingeropolous> found my old bitcointalk posts: https://bitcointalk.org/index.php?topic=1045373.0;topicseen . But they have since butchered their coin with masternodes.
20:11:12 <gingeropolous> right, we only need self select pools
20:11:17 <gingeropolous> but no pool operator is going to do it
20:11:35 <sech1> or at least self-select ports on existing pools
20:11:58 <moneromooo> What's the drawback(s) for pools ?
20:12:09 <Inge-> Centralization?
20:12:23 <gingeropolous> there's none, its just that its more work. miners won't want to do it either. they need to run monerod then
20:12:44 <moneromooo> Fair enough.
20:12:59 <gingeropolous> so if you do boolberry-type blockchain read, you force running of monerod, so at least they have that
20:13:02 <sech1> One node per miner will be enough, they just need to set it up somewhere. But yes, it's more work
20:13:08 <sech1> Miners won't do it unless such pool pays more
20:13:23 <sech1> I mean one node for all miner's computers
20:13:25 <gingeropolous> right. i pitched that to m5m500, it didn't fly
20:13:43 <gingeropolous> M5M400
20:14:03 <gingeropolous> and of all the pools, you'd think supportxmr would be the one to do it
20:14:06 <moneromooo> Maybe you just need to actually upgrade to the 500 version then ^_^
20:15:34 <gingeropolous> is there a way to hack in blockchain reads into randomx?
20:15:57 <sech1> please no
20:16:11 <sech1> we're done with tweaks, right?
20:19:06 <gingeropolous> well this isn't really related to specialized hardware
20:19:24 <moneromooo> Possibly, possibly not. I wouldn't want to say no before seeing conditions in the future.
20:19:38 <defterade_> pool-resistance is stupid, you incentivize large scale mining operations and botnets and drive out hobbyists and small operations who are more sensitive to bad luck.
20:19:49 <gingeropolous> yes, i know
20:20:06 <gingeropolous> we need to find a way to enforce cooperative pooled mining, not master-slave pooled mining
20:20:18 <defterade_> right, okay
20:20:23 <moneromooo> It's only stupid if the pools are small. And vice versa.
20:20:24 <sech1> p2p pool, self-select pool
20:26:03 <kinghat> its not possible for the network to have its own pools? maybe geographically load balanced?
20:26:22 <moneromooo> It is. It's called p2pool.
20:27:42 <sech1> It didn't take off with Bitcoin though
20:27:48 <kinghat> would the pool fee go to those who take the burden of host the resources for it? kind of like we have with nodes now? or would there be no pool fee since its all centralized in a decentralized sort of way?
20:28:07 <sech1> It's configurable
20:28:18 <sech1> p2pool runs on a consensus between all pool's miners
20:28:34 <sech1> if pool's code has fee, all miners must agree with it by mining on that pool
20:28:51 <moneromooo> There is no pool per se, so no pool fee.
20:29:05 <sech1> yes, but the way rewards are distributed
20:29:07 <moneromooo> Everyone hosts the resources.
20:29:12 <sech1> it's done in pool's code
20:29:28 <sech1> so it can have dev wallet's address in each mined block with some small fee
20:29:54 <moneromooo> Sure, but that's unrelated to p2pool.
20:30:01 <moneromooo> It could be done with monerod too.
20:30:15 <moneromooo> Now I mean.
20:30:22 <sech1> yes, it's more like dev fee, not pool fee
20:30:42 <kinghat> maybe thats not what im thinking of then. this would be one big network pool, which is divided and balanced dynamically by whatever makes sense, and those are they only pools to mine to. would probably have to do away with individual mining as well?
20:30:51 <sech1> but nothing prevents miners from forking the code, removing fee and mining there
20:31:49 <moneromooo> You can have any number of p2pools, so not one big network pool necessarily. You could have a few with different rules for the sharechain (ie, share difficulty).
20:32:52 <moneromooo> I expect you could even have geographically located p2pools. Anyone can join from elsewhere, but have more orphan risks :)
20:33:27 <moneromooo> Could work well for China, if they can find one place that has fast ping to outside China.
20:33:39 <kinghat> remember, im dumb, but what you guys are talking about sounds more like users can setup their own pools still?
20:33:56 <moneromooo> It's permissionless, yes.
20:34:41 <moneromooo> Though it's not really "their own", same as it's not "your monero network".
20:34:54 <moneromooo> You use it as you will, others do too.
20:35:23 <moneromooo> I guess the comparison is a bit meh.
20:35:38 <kinghat> if you couldnt and you could only mine via the network pools that itself created but hosted via the users, couldnt you prevent a 51% attack as the network pools obv dont want to attack itself?
20:36:18 <moneromooo> Well, the network pools aren't sentient. They're just the sum of their miners.
20:37:16 <moneromooo> You also cannot mine only via the p2pools, since p2pools ultimately follow the existing consensus rules when adding a block.
20:37:37 <moneromooo> If you require metadata showing it's from a p2pool, it can be faked too.
20:39:55 <kinghat> so someone with enough hash could still 51% but controlling the pools would at least stop a pool from going rogue? which has a better chance of 51% than an individual.
21:21:37 <defterade_> i don't see how large master-slave mining pools are a threat to decentralization
21:21:44 <defterade_> how are colluding pool operators going to diverge enough hashrate for long enough to pull off a double spend without alerting everyone of their attempt
21:21:55 <defterade_> do we expect miners to not care / notice soon enough?
21:22:17 <defterade_> perhaps only if mining power is highly geographically centralized, you could launch an attack at night
21:22:41 <defterade_> a certain outcome is that participating pools lose a reliable source of income
21:23:11 <defterade_> besides, exchanges and merchant should already factor in double spend risk in the number of confirmations required for large deposits/payments so realistically there is not much to gain from a double spend in a shallow reorg anyways
21:23:55 <defterade_> i wonder, are transactions that have disappeared from the blockchain as a result of a reorg put back into the mempool?
21:28:27 <defterade_> because that would impair a reorg with empty blocks and short the market approach for chains with low blocksize pressure
22:45:21 <gingeropolous> <defterade_> how are colluding pool operators going to diverge enough hashrate for long enough to pull off a double spend without alerting everyone of their attempt >>> while that may be valid, to me its too dependent on people being good.
22:45:40 <gingeropolous> the point of this whole system is to remove that dependency
23:00:09 <gingeropolous> i mean hell, if we're gonna depend on people being good, then we should just embrace ASICs. gazing!
23:00:13 <gingeropolous> gah-zing!
23:16:59 <needmonero90> Yeah but what if a government funds an asic fab to make enough asics to 51% the network?
23:17:09 <needmonero90> Bet you never thought of that one