08:00:32 6 months of RandomX today? We're already past block 2110193 (1978433 + 183*720). 08:35:40 equihash is not a hash, so try get rid of that part 08:36:05 (it's not equitable either for that matter:-) 11:44:42 I always wondered where the "equi" was. 11:45:19 sech1: yep, Nov 30 - May 30 11:46:06 It's latin for horse. Pile of horsehash (j/k, I have no idea how good it is). 11:47:08 Like Cryptonight, it worked ok for a while but ETH is being overrun with ASICs now 11:48:03 the GNFS discussion on reddit highlighted one point for me - anything GPUs can do, FPGAs and ASICs can do better 12:03:49 tromp: true 12:03:58 btw I used your equihash solver for testing, but then I decided to implement my own 12:05:44 Miners: 40130. So after 6 months, miner count finally restored to pre-RandomX values. 12:24:05 lies, randomx was supposed to kill monero mining! No ones interested in a bonnet coin! 12:24:39 clearly it is now 150% botnets and no legit miners any more 12:26:44 so where did the forced signing of blocks idea fall? 12:28:05 i wonder if pools would offer proxy sigs 12:28:34 to bypass the signing? 12:28:39 yeah 12:29:01 so you end up just trusting the pool will distribute shares 12:29:40 how would you see proxy signing work? 12:30:44 oh wait. u already mentioned: yes. there's no reason a large number of miners couldn't all use the same signing key 12:31:40 bah. stupid pools 12:44:14 it's true that big pools could refuse to mine/relay transactions spending their coinbase 12:44:44 so knowing the private key may not be enough to actually steal the funds 12:56:00 so you believe requiring miners to sign blocks is a viable way forward? to require miner self-select? 12:57:34 actually my comment implied that I'm not sure it would work in practice 12:58:13 if the miner who mined the block knows the private key, but cannot spend the output, then it's all for nothing 12:58:52 the pool could require a deposit of 1 block reward before you start mining, and each miner gets their own spend key. if a reward gets stolen the pool can take the deposit and ban the user 12:59:41 That kicks small miners while only allowing large ones. 13:03:21 tevador I didn't realize that was an objective. I thought the goal was to allow pools to continue to operate, but just forcing individual miners to construct the blocks 13:03:33 the block reward would still go to the pool, to be distributed by the pool 13:09:40 block signing does not force miners to construct blocks, the pool can simply send the hashing blob and the one-time private key p = H(r*a*G)+b, where r is miner-specific, a is the private view key and b is the private spend key of the pool wallet 13:10:23 yes, we already discussed that 13:11:16 the original objective in the wownero issue was to block pools in general 13:12:06 large pools in particular 13:12:46 that seems like the wrong goal, it will eliminate everyone who only mines for the small predictable reward 13:14:10 if you force everyone to solo mine, most people will say screw it. the lottery aspect will turn them all off 13:16:08 Loads of people play the lottery. What we're missing is maybe the possibility of a large reward. So... if your block hash is enough for 1000 times the difficulty, you don't get get 3 monero, but 3000 monero. 13:16:19 one-time private keys and 1.66 XMR deposit can actually enable pool mining again. Even if miner who found a block tries to spend the reward and succeeds, pool will see the block anyway and take the deposit to compensate. 13:19:31 requiring a deposit will exclude all new miners 13:19:42 raising barrier to entry is also a bad idea 13:23:40 a monerp block in no way compares to a lottery prize that that people play for 13:52:28 moneromooo, that's a neat idea that I don't think has been tried out in practice afaik 13:52:59 dogecoin had pseudorandom block rewards, but it wasn't based on the amount under/over diff target the winning hash had 13:53:05 and it was gamed so they removed it 14:05:29 messing with the emission curve seems like a risky thing to do 14:14:39 Risky for monero, or risky ? For monero, it'd be reneging on guarantees. 14:15:57 I could see a very large miner finding a block and deciding to continue trying in case there's x1000 found soon. 14:16:21 Cumulative diff would have to use the base diff, not the x1000 (or one could rewrite a lot on a stroke of luck). 14:16:30 Anything else that makes it risky ? 14:36:50 could also just increase the blocktime. that would increase the block reward / lottery . but prolly not enough 17:17:35 i just wish there was a way to get rid of private pools and have it all managed and balanced by nodes, geographically or however, that the whole community operates. technically its one big pool but split out into balanced pools however the network seems fit. 17:22:00 one big pool? with microscopic payouts to everyone? 17:22:47 couldnt you set your payout threshold like pools currently offer? 19:07:20 here is the new PoW: https://github.com/tevador/equix 19:08:34 What areas does it improve ? 19:09:35 50 μs verification with 0 memory, for one 19:13:49 the objective was mainly to cripple GPUs and FPGAs; ASICs will probably outperform CPUs 10x but custom chips will be harder to develop than for CN variants 19:24:40 Wait. Hypothetical ASICs don't outperform CPUs right now, right ? Or not by much. Remove unused silicon, that's pretty much it. 19:24:56 IIRC sech1 estimated 2x as a plausible gain. 19:25:21 for RandomX? 19:25:25 Yes. 19:25:36 RandomX is safe from ASICs 19:25:59 Is 10x safe by your definition ? 19:26:10 I would even say RandomX is an overkill 19:26:43 moneromooo: 10x was referring to Equi-X 19:27:23 I got that, but based on my naive understanding, you're saying it is expected to perform worse (10x vs 2x). 19:27:33 At least on that metric. 19:28:00 maybe and maybe not, it's all guesswork 19:28:50 but RandomX is somewhat more resistant due to the 2 GB memory requirement 19:29:39 bearing in mind that memory density doubles every 18 months ... 19:30:08 I wouldn't call RandomX overkill 19:30:42 Some level of overkill is probably needed since there's bound to be things you didn't think of. 19:30:57 I can't recall why we scrapped growing dataset idea? 19:31:02 We even had it implemented 19:31:39 it would also grow the cache size and I think there were objections to that 19:35:19 hasn't ETH already grown beyond 4GB GPUs? 19:35:37 I looked it up the repo, the dataset was growing by 2 MB per 1024 blocks, so around 512 MB per year 19:36:00 it was in RandomX 0.3.3 19:37:03 ETH is close to 4 GB, but still has a few more months to go 19:38:29 ah ok. 3GB GPUs are already dead 19:38:33 btw what happened to the Linzhi ASIC? DoA? 19:38:50 Linzhi ASIC for which algo? 19:38:54 Eth 19:39:09 they were supposed to ship this spring IIRC 19:39:27 https://en.ethereumworldnews.com/linzhi-begins-production-of-powerful-ethereum-miners-to-be-450-more-efficient-than-current-hardware/ 19:39:27 Corona happened? (just speculating) 19:39:40 yeah their shipping schedule prob got trashed like everyone else's 19:39:58 a bunch of stuff I ordered Jan-Feb timeframe is still in limbo 19:40:02 I don't think it's corona, they have been silent since January 19:40:16 I think their first batch of chips were duds 19:41:05 so Sept last year they were predicting production by Feb this year 19:41:11 no way that Corona didn't impact that 19:42:24 they got their chips in December 19:42:40 https://twitter.com/LinzhiCorp/status/1208092925235732480 19:42:44 their last tweet 19:43:17 they expected samples in December, so at least that was on schedule 19:44:15 but their chip bringup didn't work I guess 19:45:54 or they just shut the company down while corona and CHinese New Year were happening 19:46:01 "we expect them to be back around mid to end November, and then we will start with the bringup, which means we will test whether the chip converts power into, perhaps, some calculations, or if it’s more interested in converting power into smoke" 19:46:10 I guess it was smoke then! 19:46:13 lol 19:46:38 from here: https://medium.com/@Linzhi/linzhi-e1400-architecture-overview-6fed5a19ef70 19:46:50 there's no way they were doing any productive work between January and February 19:47:02 and probably most of March as well 19:48:30 we should consider those 3 months as just dead time. likewise for anyone foolish enough to try to develop a RandomX ASIC, those 3 months were writeoffs 19:48:52 it's almost June 19:48:58 yeah 19:49:19 but like I said - I'm still waiting for some gear I ordered back in Jan-Feb 19:49:31 one item I ordered in January got delivered a week ago. LED array. 19:49:54 shipping schedules are only now beginning to recover 20:44:59 https://xmr.nanopool.org/account/49DSeWApDUwFk3bY3Y5WBzbHjxnFHiHBnKqRKuQVw6thLcsD3qHMe7egkpME219afYjYih31anEEncgMU65AsPMRQsqn9bn 20:45:11 same guy or next noob without proxy ramping up 20:52:30 a bit early for my timezone. must be in Asia