Hashrate as a reference to price.

[stan.distortion]

As mining hardware develops the gains will be smaller and smaller with most gains eventually coming from improvements in IC tech. That means at some point hashrate can be used as a built-in reference to price, not an exact reference but certainly adequate for keeping things like proposal and transaction fees in line with market behaviour. It looks like that point is getting close, this paper is for BTC (so only sha256) and the findings suggests price and hashrate are becoming more and more tightly aligned:

https://medium.com/coinmonks/bitcoi...ed-by-hashrate-but-only-by-money-6e6ab2dd21d0

 

[Darren]

George Bissias has a paper or two on this.

https://people.cs.umass.edu/~gbiss/

https://arxiv.org/abs/2012.03706

https://arxiv.org/abs/1907.09883

I'm not sure these are the papers I'm thinking of. There's a paper that predicts the price of one crypto in another based on relative hash rates even if they use different proof of work. I think data from the market NiceHash were used.

 

[stan.distortion]

Thanks, interesting to see it being researched in depth. I see they've already addressed altering difficulty adjustment methods to avoid exploits (something Dash addressed from the very start). Do you know of any research on using it as negative feedback, using it as a basis for adjusting emission as a stabilising mechanism? Hardware development probably has a few years to go before something like that would be viable but it seems like it could be a big step forward when it gets there.

 

[Darren]

Funny you ask that here.

Dash actually has a negative feedback mechanism in it. If the difficulty drops enough then the emission will increase. However, this was designed before ASICs. Basically, as long as one miner is using an ASIC there's no chance of the difficulty dropping to a point to change the emission. I think it's still in the code, no reason to remove it.

George's work used the market rate for hashrate exchange. So there was still some human determined information needed to understand the price.

I would love if price could be securely used in the protocol.

 

[slamdunk]

I think it's still in the code, no reason to remove it.

totally respect you Darren and you're much more familiar with the codebase than me but...eeek

 

[stan.distortion]

totally respect you Darren and you're much more familiar with the codebase than me but...eeek

Iirc it was removed, I was checking up on what effects total emission a while ago and I'm fairly sure it was written out and only unallocated budget could effect total emission now. Hope I'm wrong about that because I've long felt our unfixed (but limited) total emission could be an ace up our sleeve, that it could allow us some wiggle room for an actual economic policy where others are hamstrung by set-in-stone emissions leaving them totally at the mercy of markets.

I was totally wrong on the negative feedback thing above, increasing the emission with increasing hashrate would cause serious problems, it would amplify the effect (price to hashrate) and the delay between price change and hashrate change would cause potentially explosive hysteresis.

The opposite would be beneficial to some degree, reducing emission as hashrate increases (and vis versa ofc), it would reduce noise as a price oracle and could also help reduce lag but it would have exactly the wrong effect on value stability, reduce the emission as prices rise when increased emission to counter the rise is needed.

It could still serve as an oracle for that though and that would allow emission to be increased elsewhere and that could be really powerful if targeted at actual usage, people spending Dash. Crypto spending increases during rising prices and cashback could potentially be used as a tool to both increase emission to counter price spikes and amplify that increased spending effect.

 

[Darren]

I'm convinced that the current Dash emission schedule will allow for safe use and scaling of DASH for at least the next two decades.