There are different types of “super blocks” of varying frequency.
Extract from, https://eprint.iacr.org/2019/1444.pdf, “We measured the superblock distribution in the mainnet Bitcoin blockchain. Our results are illustrated in Figure 1. As expected, half the blockchain blocks are 1-superblocks, 1/4 of blocks are 2-superblocks and generally approximately 2^−µ of the blockchain blocks are µ-superblocks.”
So we could potentially use a type 4-superblock (every 16 blocks on average) or something that occurs more or less frequently but at random.
Honestly with the amount of gpu hash floating around after the merge it makes sense to have the difficulty adjust based on the most recent previous blocks.
Miners will be swapping to the most profitable algo no doubt.
A large enough sample of blocks is need imo to slow the rate of change down based on recent blocktimes to the desired average.
After all that is what is desired. A stable regular block interval of 2 mins.
Hence my suggestion of dark gravity wave with a look back at the previous say 100 blocks, or 200 mins, and that will adjust the difficulty up or down as needed. The difficulty adjustment period can of course be adjusted to whatever parameters are preferred.
Ravencoin adopted DGW with a 180 block look behind early on in their lifecycle when it became gpu mineable and profit algos the miners use were causing the rvn network difficulty spikes. I know. I was there for it.
Their difficulty and hash follow each other pretty nicely now. Just offering suggestions.
Be interested to know why block difficulty targeting is not on the table as well technically.
Would it be possible to have a softfork that sends a percentage of the block rewards to a box when block time is under a certain threshold? The box empties again during slower blocks. It would help smooth out the overpayment of erg in the first part of a sudden extreme hashrate spike and save some for later to help keeping miners to stick around. My guess would be that something like that would be doable by softfork since the diff adjustment itself remains untouched.
This is similar to my thinking, but we don’t require any forks, just smartpools.
We can create smartpools that include a slush fund that pays out to miners when a sharp and sustained increase in difficulty is detected on the network.
The slush fund can be funded both or either by a constant fee on the mining pool, say 2-3% additional to dev fee; and by an opposite rule when the difficulty drops quickly (Say 20-50% of the block reward.)
This combined with a PPLNS reward model ( or at least one that can track loyalty over a long period of time, pre difficulty increase) will enable miners to see smoother rewards as the difficulty rises and falls WITHOUT decreasing the security of the network or removing voting power from miners.
Yes and the smart pool would have to track each miner as the extra rewards given during longer blocktimes should only be given to those miners that contributed during the shorter block time periods.
The above being said, I don’t think such a pool will attract miners as there is a lot more to gain by just hopping on when difficulty is low and hopping off after a large difficulty increase; either to save electricity or to mine something else.
I think this could potentially work, just need to figure out what percentage (fixed or variable) and how to apply it. A potential problem I forsee with this is that it may force constant or near-constant difficulty, which wouldn’t necessarily be a good thing as it would facilitate 51% attacks.
Variable: Percentage determined by “distance” from the ideal 120 second block time. Example: If hashrate increases and block times decrease by 12 seconds adjust reward being sent to box by 10% (if 48 ERG mining reward, send 4.8 erg to re-distribution box). If hashrate decreases and block times increase by 12 seconds then pay out from box to increase rewards by 10% (if 48 ERG mining reward, send additional 4.8 ERG).
This would essentially remove any incentive for the additional hashrate… which would keep difficulty constant. It would facilitate 51% attack.
Fixed: Probably better than variable but what thresholds would be used? Example: If block times less than 100 seconds send 10% of reward to re-distribution box. If block times greater than 140 seconds, pay out extra 10% from re-distribution box. This could dampen/partially mitigate the problem but would not resolve it. Once the re-distribution box is empty then what?
A redistribution box need not ever empty, it could award miners a percentage of it’s remaining ERG. Mining pools can charge a higher fee when block time is lower than target (on a scale as you suggest in the variable example) and the repay it to those original miners when block time is higher than target.
In a zero sum situation where every miner pool hops, and coin hops, sure. The loyal miners that mine to secure the network, the ones mining now, the ones that can afford to mine and hold; those miners will always have incentive to increase their hash rate provided they can afford their electricity.
If we kick the can with a 2nd global remission contract including a variable or fixed tax as you describe, we risk miner transaction censorship and another potential hard fork as we did during EIP 27.
If we avoid soft forks and stick to voluntary smart contract mining pools, miners can choose their risk based on any combination of your variable and fixed solutions with numbers tweaked to fit their needs.
By keeping things voluntary, miners that want to coin hop for the quickest short term profit as Ergo’s difficulty rises and falls are not disincentivized, and miners that stay loyal to Ergo can see smoother rewards should they choose to participate in a pool offering such a scheme.
If something like this is implemented and the long haul miners migrate over to pools offering smooth rewards, there will still exist profit for coin-hoppers to play around our long difficulty adjustment time until such time that Ergo represents a majority of potential hashrate in the world.
There will always be incentive to increase hashrate/ secure the network for long term holders of a fixed supply asset.
Diminishing returns from a fixed supply is a very common distribution model in crypto. Bitcoin does it, and Ergo recently adopted it with EIP 27.
The existing difficulty adjustment formula should protect such an emission box from being emptied as long as it is funded by a percentage of every block reward, but I agree that a combination of fixed and variable would be ideal.
Re-adjustment using super-blocks is NOT safe. The NiPoPoW paper explains ways that an adversary can easily mess with the distribution of super-blocks while still controlling less than 50% of the hashrate. The distribution of super-blocks is only guaranteed under the assumption that all miners are honest. The NiPoPoW paper explains ways to mitigate this effect in the context of proofs, but such techniques would not work in regards to difficulty adjustment.
Smart Pool based diff relief does sound interesting, I will look over some of the ideas posted here and give my own feedback in regards to this after some thought.
The redistribution box system seems like an interesting option, also avoiding HF?
What about the current system? Why was it chosen, how was it tested, what are the key pros? How do the key pros rank in evaluation, like the list mentioned in the conclusion of the BCH DAA article? How about the key cons & evaluation? Regarding the BCH DAA article, DAA system simulation with existing data (especially now with the Merge event last week) seems essential to evaluate how any proposed system change behaves in real-life stress tests.
Sorry for mostly asking questions, just scratching the surface of the topic today.
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.
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.
