"We are researching a new mining algorithm, as well as other changes"

I wonder what they come up with. Maybe RandomX variant?

Either ProgPow or RandomX variant, I just don't see any other easy to integrate algorithms for them

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

yeah, it's progpow or nothing for them

they'd have a full scale revolt if they tried to adopt randomX

oh eth classic

"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

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?

What is the purpose of the random lock time?

Inge-: wownero is adding a random lock time to try and prevent profit switching miners, not sure what it would do in monero though

hm

Why random and not fixed long ?

good question

eh? if it's a fixed time they can still profit switch

they'll know exactly when to come back

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 ?

it prevents them from dumping their mining rewards quickly though. by time they can sell it the price will probably be 0 :P

A fixed long time prevents the "asap" part, and the exhange rate will have randomly moved away.

any predictable time interval works in their favor

by the same token, I've always wondered about the fixed unlock time in the wallet

instead of allowing you to spend immediately, you have to wait 20 minutes. so big deal

you can just monitor for all spends within 20 minutes of receipt

fixed intervals don't change the probabilities

I don't understand "any predictable time interval works in their favor". Can you expand ?

If anything, reversion to the mean will tend to move the price down if they wanted to mine in times of high prices.

if miners dumping are the primary downward pressure on the price, they will still be the same pressure, just delayed X minutes later

if they're the primary pressure, nothing else is going to change things during those X minutes

you're just making the pipeline longer, but not changing the overall outcome

just like in a CPU pipeline.

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

compared to a CPU with a 4-cycle pipeline, that also completes 2 instr/cycle every cycle, once its pipeline is full

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.

once their pipelines are full ,the two are indistinguishable

and on-off miners are unlikely to be the primary driver, since they're temporary.

Other miners also sell, and those would get less, since emission is ~constnat.

also, the fed should apply a random 25 basis point move of interest rates

Ah, the IRC curse of sending to thre wrong channel every once in a while :)

pfft

but if on-off miners and long term miners are subject to the same fixed delay, there's still no mitigation of their impact

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.

s/see/sell/

long term miners can't sell any faster than the on-off miners

I don't see how that matters.

therefore, they can't overshadow the on-off sell pressure

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

i was thinking more in terms of pool centralization. it could be that introducing a random lock causes pool administration to be more .... risky.

thus, they would increase fees to accommodate for this risk

presumably, larger pools would counter the random lock with an offer to still pay out regular payouts

but they'd need a slush fund to do so

so larger pools with larger expenses might have to have higher fees to create the slush fund and keep things going

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

so their fee increase to create a slush fund would be less

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

furthermore, smaller pools (take monerohash for instance) already have a dedicated core of users that are accustomed to longer payouts

i mean, thats not a small pool, its a medium pool but the point is the same

asymptotically, Inge- ^

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

i think it would stop being a problem after a short while of mining

nobody mining to a pool expects an immediate payoff. it always takes time to reach the payout threshold

true

cryptoconomist

a big reason that people use big pools is for a more immediate payout

also true

i mean, if people didn't mind variance they would solo mine. people mind variance.

gingeropolous: if random reward reward lock times become a thing, so will be PPS pools (which are currently a comperatively high-fee niche)

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

so if the goal of the exercise is to prevent pool hopping and diff rocking... I think it will not work

currently one wow pool has 73.5% of the HR

I think that this is one of the issues that is trying to be addressed

it's a 1% fee PPS+ pool

they probably automatically dump the rewards on tradeogre and exchange as soon as it unlocks

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?

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?

2mb is not big, it's barely a minimum to be memory hard

android phones have power efficiency not worse than Ryzen CPUs

What be the problem of not being memory hard? Most of the arm chips do have a lack of cache.

Why exlcuding these devices by raisng the cache barrier?

*What would be

Memory hard algos are a common path to ASIC-resistance, as it raises the cost/size/complexity of ASICs

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.

seth: But couldnt an asic company just slam ton of arm cores with enough cache on a board?

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

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.

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

But I'm by no means the expert here so could be off on some of these points :)

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?

Isnt randomx mostly relying on cpu operations like branch prediction floating point operations etc. ?

Thanks, selsta :)

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?

2 MB scratchpad is there to make each computing core big, to prevent ASIC from having thousands of cores on a single chip

they can store scratchpads in external memory together with dataset (HBM2 for example), but it hurts power efficiency a lot

actually no. ARM is slightly worse than AMD Ryzen in efficiency with randomX

mainly because of typically small caches on ARM

ARM is still ahead of Intel efficiency tho

but I'm not sure if that would still be true, if ARM chips scaled clock speeds up to match Intel

I didn't say which Ryzen

1st gen Ryzen ~ ARM in efficiency

hyc: Do you know why ARM does have less cache compared to amd? Is it just because of the cache costs?

or does cache consume that much energy?

sech1: Interesting...

Might it be possible that our cloud miner went solo mining? There is a 160mhs gap between pool hashrate and network hashrate.