That’s the paper by Ergo devs describing the reason behind DAA choice. I agree with you on that last point, I really think we need to utilize the tons of research and testing done by BCH on this matter (along with any others that can help), and then test test test before all else.
The soft fork options from what I’ve seen so far are FAR from simple, personally rather HF and address any other changes we seek while doing so, than SF following complex and unproven method to change DAA.
Second thread here
Hard-Fork Upgrades Wish List
Summary thread (pre-community discussion):
Article from Armeanio - Ergo Post Merge Community Discussion: Difficulty Adjustment
Community discussion from yesterday
I’ll have to read into how adversaries can mess with the distribution of super-blocks and whether there is any incentive to do so with regards to adjusting difficulty.
Hello guys. Isn’t there a reason why the dampening of the difficulty downwards time can’t be made shorter?
My take is that from this event we can observe due to the delay in diff adjustment (down) a sudden drop down in hashrate creates (1) longer block times which creates (2) less profitability for miners that (3) causes more miners to leave which (4) drops the hashrate even more.
I understand the design according to the paper is to prevent coin hopping attacks, but the current event is less desirable.
What is the downside of reducing the adjustment time?
Reading the paper “Revisiting Difficulty Control for Blockchain Systems” gave some sense to the reasons why the current DAA was chosen. With the delayed difficulty adjustment, hopping between coins makes less sense. However, as augustov above mentioned, reducing the difficulty is very slow, as block time and difficulty adjustment time are related in a linear way. This also means that if the difficulty falls too low, it should be quick to pick up, as seen lately.
My question is; is it possible / detrimental to detach difficulty adjustment (reduction) time from block time? For example, use the target block time instead of current block time? Is there a benefit to keeping this attachment? Naturally it’s only a part of the solution, but this would surely help; the next difficulty adjustment wouldn’t be so far away in the current situation.
Is it possible/beneficial to have an additional difficulty temporarily added for new miners when the block times are faster than normal?
That would be against the manifesto’s commitment to avoid censorship imo.
Is it possible to vary the block reward on the fly? We could leave the difficulty per epoch moving average as it is and drop the block reward by x amount during a spike in hashrate of y and increase the block reward by x amount when the hashrate drops below some target amount y. A large farm or pool entering the network spikes the hashrate block reward drops by from 10% to up to 90% once the spike is detected. Same end result except that now the short term profitability prediction wont be accurate enough for large farmers that coin hop to rely on to know when to jump in unless they were in for the long term
Security analysis (for both NiPoPoWs and classic blockchain security properties from GKL15) would be complicated in this case, if doable at all
I made some modelling and it seems making epoch length shorter just would make difficulty more bumpy. I am looking into smoothing it something like following:
For most of epochs results are similar (difference with current algo is within 10%), but during turbulent times (after HF and now) this method is catching up with reality at a faster pace.
For epoch length, I guess, 128 blocks is the safest option from short ones.
My main thing as a small miner is not profitability. The mining community has, for a long while, known that we would enter this mining profitability wasteland post-merge. As such the concerns and suggestions I mention are not coming from a place of delusion, believing that even if the network hardforked, we’d still be unprofitable/barely profitable for the foreseeable future (1 year+ or until the macro outlook reverses course)
So my desire to have something to done regarding the current difficulty adjustment mechanics stems from my being someone who wants to see Ergo win and also invests (DCA) in Ergo beyond the simple $ERG denominated revenue my 6 card rig generates.
As it stands, the GPU mining landscape is much akin to a John Carpenter-esque, PvE, dystopian jungle. The degree to which the PvE raider mining practices occur increases proportionate to the $$$ amount of overhead any one mining actor has to sustain.
I mention this, because I have seen several tweets conveying a message effectively saying: “Don’t worry, this is the first week, give it time, it’ll sort itself out.”
I think anyone holding this perspective doesn’t fully appreciate the degree to which the GPU mining economy has been destabilized by Ethereum’s transition to PoS.
Mining is now a wholly nomadic enterprise and should continue to be so for the next few years when factoring current macro conditions, with the reality of the long road that faces any PoW L1 chain seeking to build an economy of Ethereum’s magnitude, constituent popularity, developer ecosystem and associated coin/token value.
Understanding that this is the state of GPU mining, that even if actors want to exit the game, there are few eager to buy the hardware that the myriad operations of varying scale may before long seek to liquidate, that there is no “ol’ reliable” to fall back on to keep the lights on anymore, entails that any difficulty adjustment mechanics that can be gamed to the benefit of a few miners, will be gamed, health of the network be-damned. Vampirism and self-preservation are running the show.
The problem with Ergo’s current difficulty adjustment mechanics is that which it is quick to increase difficulty, it is slow to decrease it.
What we just days ago was the network inundated with hashrate, the difficulty skyrocketed (as it should) rapidly due the significantly decreased block times accelerating the network’s march to the next epoch. Then, once the difficulty had adjusted to never before seen levels, a mass exodus of hashrate began as the network profitability plummeted.
The problem the remaining Ergo miners were left with was that our relief, the next difficulty adjustment, would be slow to come as the checkpoints for difficulty adjustment are governed by a naked block count not factoring for passage of time in the real world. When the hashrate exodus occurred after the difficulty spike, with difficulty so high and hashrate gutted, block times increased significantly.
I would very much like to see more dynamic difficulty adjustment mechanics explored, mechanics that by whatever suitable means, account for avg block times and increase or decrease the # of blocks to next diff adjustment accordingly with a target average blocktime being used to guide the development of the rule set.
Profitability is a lost cause. What I care about is the stability of the Ergo network both from a security standpoint and an end user UX perspective. What kind of UX is being delivered if the network is only fast one day a week and reliably sluggish the other 6 days until we adjust back down; rinse and repeat. When somebody buys a piece of this network in the form of $ERG, is this what they want to hold?
Fortunately, we saw no issues from this initial hashrate cycle surrounding blocktimes being too fast, but it is a technical possibility.
Again, my desire here is to mature and harden the network, to enhance its resilience where possible. For me this is all about design optimization. Good enough is good enough until it isn’t. This instance shined a light on something that, without such novel circumstances, may never have been discussed. I say we take this opportunity to fully explore the potential benefit to the network of entertaining alternative difficulty adjustment mechanics in earnest.
Lastly, maybe the chain hopping dies off soon. However, I am very dubious. There are few serious GPU Mineable projects in the market lineup and there will continue to be plenty of attention on Ergo in the years ahead. As currently, it is exceptionally easy to monitor and time the next difficulty adjustment to exploit as the block times between are at a crawl. A more dynamic adjustment mechanic would mean that actors would have to expend more time and effort trying to time and game the difficulty producing an increasingly diminishing return on investment for mercenary miners the more effectively dynamic the adjustment mechanism selected is.
Regards,
MintemPrintem.HashCartel
Would a hard fork be required, or could voluntary mining contracts of constant hashrate (hashrate present pre and post merge) be enough to get close to 10% without an autoritative change?
Thanks a lot for this!
Is it possible to see how different epoch lengths would play on the current situation, for example last week? To see the bumpiness, adjustment time etc. If you have the models, of course. Thanks again!
A hybrid algorithm which leaves the current formula unchanged, but makes the curve more symmetric.
Really great post. I wish the same things as you.
Right now, the system rewards the big miners, and punish the home miners who love and support the network. I think this is not fair, feels like to do the hard part of the job for rich people.
It is hard to simulate shorter epochs, as we do not have blockchain data for points between every 1024 blocks. So I used 1024 blocks long epoch and compared with what we do have with the current algo.
I published some modelling code in Diff modelling by kushti · Pull Request #1842 · ergoplatform/ergo · GitHub , the code is garbage though, and you need to have a local blockchain db to work it,
I also discovered that epoch length was 256 initially, but then was changed to 1024, likely as initially it was the same setting for difficulty and voting epoch, then the setting split into two but the diff epoch value remained intact.
Hard fork is required.
Rewarding is done via a smart contract, so it would hard to change anything there.
Aha yes of course, thanks for the clarification.
I had an idea, ofc i don’t know if it’s possible to do it, but… typing it’s free so…
Leave everything like now, but with one modify, If block time > 4 min, run again a difficulty check
if block time < 40 sec, run again difficulty check.
The fact is, i don’t know if we can change difficulty and do a difficulty check in the middle of the epoch 
Sry if i said somentingh totally wrong, i’m new here The fact is the epoch drifted one day and a half, in less than one day… we don’t have much time unlickely…