09:00:05 https://medium.com/ethereum-classic-labs/edcon-2020-ethereum-classic-resilience-734ff9c3c499 09:00:11 "We are researching a new mining algorithm, as well as other changes" 09:00:34 I wonder what they come up with. Maybe RandomX variant? 09:07:31 Either ProgPow or RandomX variant, I just don't see any other easy to integrate algorithms for them 12:08:35 oh man that'd suck if eth enters the general compute space. I can't see how their GPU miners would be for it though 12:09:10 yeah, it's progpow or nothing for them 12:09:34 they'd have a full scale revolt if they tried to adopt randomX 12:10:45 oh eth classic 12:12:11 "While some mining pools can improve their systems to encourage honest mining for sure, they are not responsible for the security of the network and we don’t want them to be." indeed 12:21:15 but M5M400 , how would you guys handle a new protocol rule that puts a random lock time on the block reward, between 1 and 30 days? 12:37:15 What is the purpose of the random lock time? 12:38:12 Inge-: wownero is adding a random lock time to try and prevent profit switching miners, not sure what it would do in monero though 12:39:01 hm 12:41:06 Why random and not fixed long ? 12:43:59 good question 12:45:35 eh? if it's a fixed time they can still profit switch 12:45:40 they'll know exactly when to come back 12:47:35 AFAIK "profit switch" is "the current exchange rate for this coin is high, so let's mine it and sell asap". Is that not right ? 12:47:48 it prevents them from dumping their mining rewards quickly though. by time they can sell it the price will probably be 0 :P 12:47:55 A fixed long time prevents the "asap" part, and the exhange rate will have randomly moved away. 12:49:48 any predictable time interval works in their favor 12:50:33 by the same token, I've always wondered about the fixed unlock time in the wallet 12:50:51 instead of allowing you to spend immediately, you have to wait 20 minutes. so big deal 12:51:06 you can just monitor for all spends within 20 minutes of receipt 12:51:15 fixed intervals don't change the probabilities 12:51:38 I don't understand "any predictable time interval works in their favor". Can you expand ? 12:52:12 If anything, reversion to the mean will tend to move the price down if they wanted to mine in times of high prices. 12:54:25 if miners dumping are the primary downward pressure on the price, they will still be the same pressure, just delayed X minutes later 12:54:46 if they're the primary pressure, nothing else is going to change things during those X minutes 12:55:55 you're just making the pipeline longer, but not changing the overall outcome 12:56:12 just like in a CPU pipeline. 12:56:48 e.g.: maybe you have a CPU with a 10-cycle pipeline, that completes 2 instructions a cycle, every cycle, once the pipeline is full 12:57:07 compared to a CPU with a 4-cycle pipeline, that also completes 2 instr/cycle every cycle, once its pipeline is full 12:57:17 Ah I see. Self feedback. If they're not the primary pressure though, but a random walk, a fixed long delay does mitigate the behaviour. 12:57:22 once their pipelines are full ,the two are indistinguishable 12:58:12 and on-off miners are unlikely to be the primary driver, since they're temporary. 12:58:42 Other miners also sell, and those would get less, since emission is ~constnat. 12:58:58 also, the fed should apply a random 25 basis point move of interest rates 12:59:25 Ah, the IRC curse of sending to thre wrong channel every once in a while :) 12:59:58 pfft 13:00:19 but if on-off miners and long term miners are subject to the same fixed delay, there's still no mitigation of their impact 13:01:21 I don't see why not. They want to see at inflated prices. They can only do that with high certainty if they can sell as soon as possible, to avoid reversion to the mean. 13:01:30 s/see/sell/ 13:02:07 long term miners can't sell any faster than the on-off miners 13:02:20 I don't see how that matters. 13:02:30 therefore, they can't overshadow the on-off sell pressure 13:11:24 i don't think its about price, more about chain / network stability. but yeah, if there's a long lock, then miners can't sell immediately, so there's less incentive to hop on and mine 13:12:21 i was thinking more in terms of pool centralization. it could be that introducing a random lock causes pool administration to be more .... risky. 13:12:33 thus, they would increase fees to accommodate for this risk 13:12:57 presumably, larger pools would counter the random lock with an offer to still pay out regular payouts 13:13:02 but they'd need a slush fund to do so 13:13:28 so larger pools with larger expenses might have to have higher fees to create the slush fund and keep things going 13:14:11 whereas smaller pools, which have less costs (because they're not running 50 thousand servers in every nook of the world), won't have that much overhead 13:14:30 so their fee increase to create a slush fund would be less 13:15:14 thats all perhaps. I'm no crypto-mining-economists. thats why im trying to get M5M400 's feel for what they would do as pool admins 13:16:15 furthermore, smaller pools (take monerohash for instance) already have a dedicated core of users that are accustomed to longer payouts 13:16:32 i mean, thats not a small pool, its a medium pool but the point is the same 13:19:09 asymptotically, Inge- ^ 13:21:17 as just a user and not a crypto-mining-economist i wouldn't expect a pool to pay me out early before the blocks unlocked 13:21:57 i think it would stop being a problem after a short while of mining 13:26:39 nobody mining to a pool expects an immediate payoff. it always takes time to reach the payout threshold 13:46:37 true 13:48:32 cryptoconomist 13:48:36 a big reason that people use big pools is for a more immediate payout 13:48:54 also true 13:49:25 i mean, if people didn't mind variance they would solo mine. people mind variance. 14:27:14 gingeropolous: if random reward reward lock times become a thing, so will be PPS pools (which are currently a comperatively high-fee niche) 14:30:06 also, the really big pools (provided they are fair and don't touch abandoned balances) should have a large enough sum sitting in the pool wallet to buffer a month worth of payout fluctuations 14:33:01 so if the goal of the exercise is to prevent pool hopping and diff rocking... I think it will not work 14:36:32 currently one wow pool has 73.5% of the HR 14:37:08 I think that this is one of the issues that is trying to be addressed 14:38:33 it's a 1% fee PPS+ pool 14:38:59 they probably automatically dump the rewards on tradeogre and exchange as soon as it unlocks 14:42:56 I mean, PoW has been a thing for a long time. and it's weaknesses in that regard has rekt a lot of chains. would it be fair to assume that if there was an easy solution to the problem, it would have been implemented somewhere by now? 17:17:24 Why does randomx has such a high cache barier like 2mb l3 cache per core. Wouldnt it be better to set these limits in such a way that even an android phone can mine like a normal pc? 17:22:37 2mb is not big, it's barely a minimum to be memory hard 17:23:33 android phones have power efficiency not worse than Ryzen CPUs 17:30:56 What be the problem of not being memory hard? Most of the arm chips do have a lack of cache. 17:31:41 Why exlcuding these devices by raisng the cache barrier? 17:31:55 *What would be 17:34:06 Memory hard algos are a common path to ASIC-resistance, as it raises the cost/size/complexity of ASICs 17:34:46 But it's not enough by itself, of course, so it's just part of what RandomX does to prevent ASICs having an extreme advantage. 17:40:20 seth: But couldnt an asic company just slam ton of arm cores with enough cache on a board? 17:42:05 It's not that simple, and if they did something similarly it wouldn't have a serious advantage over some guy in his garage running 100 smartphones on RandomX AFAIK 17:42:47 An ASIC could be built for any algo, even RandomX, but the point of the algo is to make it costly and reduce/remove the massive efficiency advantage normally associated with ASICs. 17:43:21 If it costs you millions of $ to fab an ASIC that is only 2x faster/more efficient than a Ryzen CPU, you're not gonna do it because the payoff would take forever 17:43:38 But I'm by no means the expert here so could be off on some of these points :) 17:54:57 Ok, but I thought the algos before randomx where already memory hard and despite of that asic manufacturers have been able to produce one. Is memory hardness really needed with randomx? 17:56:23 Isnt randomx mostly relying on cpu operations like branch prediction floating point operations etc. ? 17:57:16 https://github.com/tevador/RandomX/blob/master/doc/design.md#14-memory-hardness 18:14:15 Thanks, selsta :) 18:22:24 Am I right by saying: Randomx needs the cache barrier for making it impossible to parallel the computational part of randomx and thereby it is not possible to scale compute without scaling up caches -> No efficiency gain, because wrong ratio between cache and compute? 18:36:33 2 MB scratchpad is there to make each computing core big, to prevent ASIC from having thousands of cores on a single chip 18:38:04 they can store scratchpads in external memory together with dataset (HBM2 for example), but it hurts power efficiency a lot 19:41:19 actually no. ARM is slightly worse than AMD Ryzen in efficiency with randomX 19:41:37 mainly because of typically small caches on ARM 19:41:52 ARM is still ahead of Intel efficiency tho 19:42:11 but I'm not sure if that would still be true, if ARM chips scaled clock speeds up to match Intel 19:45:34 I didn't say which Ryzen 19:45:44 1st gen Ryzen ~ ARM in efficiency 20:02:40 hyc: Do you know why ARM does have less cache compared to amd? Is it just because of the cache costs? 20:03:21 or does cache consume that much energy? 20:05:28 sech1: Interesting... 20:08:29 Might it be possible that our cloud miner went solo mining? There is a 160mhs gap between pool hashrate and network hashrate.