Security analysis (for both NiPoPoWs and classic blockchain security properties from GKL15) would be complicated in this case, if doable at all
3 Likes
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:
- Calculate least square method based difficulty as it is done now
- Made simple diff readjustment as done in Bitcoin
- Calculate average
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.
12 Likes
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
7 Likes
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?
1 Like
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.
2 Likes
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.
2 Likes
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…
2 Likes
I’m not a mathmetician and there are people on here that are infinitly more clever than I am but I’ll give it a go…
Could the difficulty logic be amended to use a flexible number of blocks if block time goes above a certain time?
Target the block time to 2 minutes as today and have the epoch length at 1024.
BUT, if block time is more than >4 minutes the difficulty epoch length changes…
If block time is >4 minutes last 1024 blocks then new difficuty wil be calculated every 720 blocks
If block time is >8 minutes last 720 blocks then difficulty will be calculated every 360 blocks
If block time is >16 minute last 360 blocks then difficulty will be calculated every 160 blocks
And so on…I’m sure there’s even a formula that could be used to make the change even smoother than set times or # of blocks.
IF we get a sudden spike of hashrate the blocktime pain should be a lot less. Of course, it won’t prevent coin hopping, but people will do that regardless.
I’m sure this proposal has some flaws, but i throw my hat into the mix 
4 Likes
it’s + - what i said 3 hours ago lol
1 Like
I read yours but I understood that to rerun the difficulty check at the point it’s more than 4 minutes, e.g. cap it at 4 minutes.
I was thinking more a scaled approach which alters the difficulty epoch length based on the block time for the last X (variable) blocks.
2 Likes
Pretty new and dont know many proper mining terms etc here so take it easy on me.
Can the Ergo devs not do something like ScaleHashing?
New word definition, yes i just made it up.
Maybe theres something like this out there already but heres what i was thinking.
Example:
Implement an average hash limit increase for all individual miners of say… 500MH per 24 hr period. Could keep track via ip or addresses or accounts or something.
So, for any huge mining operations, they can only add 500MH to the network, would have to wait 24hr until they could add another maximum of 500MH to the network.
So itd be harder or hopefully impossible for any mining op to slap 40 GH or whatever on the network and jump off the same day.
Im crap at explaining, but i hope people understand.
Would something like this be viable and effective in preventing or at the very least extremely reducing the current issue ERG is facing?
Does something like this exist?
Would this negatively impact erg supporters in anyways?
I dont know, any constructive criticism is welcome.
Just a random lunch break thought i had.
Keep on Keepin’ on.
1 Like
How about making ergo a multi algo blockchain? We have a GPU algo, but why not also have CPUs secure the network?
Pros:
Big gpu farms wont be able to manipulate.
For times like now, blocks found on cpus will move the epoch forward without impacting gpu mining difficulty.
since the daa is epoch based, it shouldnt matter if blocks are found on gpus or cpus.
DAA wouldnt need to change.
Will give the cpu mining crowd exposure to ergo and all it has to offer.
Cons:
Crypto jackers can take advantage of the new algo on vps potentially.
Some portion of rewards (half?) would be taken from gpu miners.
Would require a hard fork.
Overall i think pros outweigh the cons but im no expert and i could be dead wrong on this. What does everyone think? Did i miss any pros/cons?
This seems the right direction to me^^
2 Likes
Problem I’ve seen with cpu miners, they tend to flock to one pool & you end up having over 50% hash rate on a single pool.
Hm, this gives me socialist vibes.