Topic: Kimoto Gravity Well Difficulty Adjustment for Bitcoin (Read 6138 times)

On fundamental level, Bitcoin is no different than altcoins and that means you have no clue what you are talking about. Maybe to study alts a bit?

http://www.coinwarz.com/charts/difficulty-charts
http://www.coinwarz.com/charts/exchange-rate-charts


Bitcoin mining community changed drastically lately, for the worse, you haven't noticed that?

P2Pool is trivial to setup and just becomes solo mining if the pooling part doesn't work for some reason (like a broken escalator becomes stairs), and it's already what everyone should be using.

...Not that setting up solo mining is hard.

But really, if you're going to bump this discouragingly stupid thread, at least have a reason for it.

The only way you'll see a major hashrate drop will be after Bitcoin is already dead.

Totally agree on that.


No one except pools and old miners know how solo mining works or know how to setup solo mining. Scenario where major pools go down for days or
more and remaining pools can not accept all miners coming from major pools is possible. If that happens and majority of miners fail to switch to solo
mining or join some other pools then we would have a situation where KGW implemented ahead of such event would be absolutely welcomed. You
may think that helping 51% attack on network is worse than having network "paused" potentially for days or weeks but I disagree on that. One can
easily combat 51% attack by increasing number of confirmations but "pause mode" can not be fixed easily and fast, as proven so many times with
many altcoins.

In other words, by not having ready a solution for prolonged major hashrate drop you people are working toward scenario where Bitcoin is likely dead.

It all works both ways. If someone adds 100% hashrate at time when difficulty retarget happened he will increase inflation by 100% for next 2016
blocks and coupled with a chance to 51% network to extreme at any moment all that would surely impact the price negatively. KGW would fix the
issue in like dozen of blocks.


Ehhh ...


It will be fun to watch them combat the shit once it happens.

Bitcoin isn't experiencing a sharp drop in hashing power.   Bitcoin is a network of anonymous peers.  There is no method to compute the exact hashrate, none.  It is impossible.  The hashrate shown is an ESTIMATE and the margin of error on the 8 hour moving average is huge (something on the order of 20%+).  

You are simply looking at noise.  


At most the hashrate declined by maybe 0.5%.  In reality that is still within the margin of error on the 3 day average so it is far more likely the network is still growing at 1% to 1.5% per day.

The only scenario where a change in the difficulty function would be of any value, is a scenario where Bitcoin is likely dead anyways. If the hashrate drops 80%+ in a two week period there probably is a larger macro economic reason, one that can't be solved by simply adjusting the difficulty faster.   

You are proposing a hard fork on a core element of the protocol for something which isn't required.  The chance of it happening is ~0%.  Hard forks simply don't happen in a consensus network for all but the most critical of changes.   If ECDSA is compromised we may see a hard fork, if there is a bug which allows someone to make a billion bitcoins out of thin air we may see a hard fork.  Anything less severe than that just has no chance of reaching a consensus.  Still if you want to beat your head against the wall you wouldn't be the first.  

Using a moving average with a box filter halves the work an attacker needs to perform in an isolation attack to get the chain down to a level where they can simulate the running network.  It also requires you to move the clamping functions much closer in to keep them equally effective, which means they become easy to hit and it's not really easy to reason about the incentive implications of a non-linear difficulty adjustment (e.g. you potentially make it more profitable to mine in bursts).

This has been discussed many many many times before.

When you do not use the search function you risk having an uninformed discussion because the more expert people have gotten tired of rehashing the same subjects over and over again for years.

It's a Moving Average.. Looking at the code could be an Exponential Moving Average, which fits in with the whole, black hole, gravity well thing..

http://en.wikipedia.org/wiki/Moving_average

It just changes the blocktime per block, rather than every 2 weeks.

I would be interested in knowing if anyone can think of any Disadvantages to using a moving average as opposed to a fixed 2 week readjust time ?

Or Vice versa..
 

KGW works for alt-coins because of the existence of multipools and similar constructs, causing the network hashrate to drop by more than half at any given moment when the multipools switch to another coin. For a coin with a hashrate that is either increasing or decreasing in a relatively smooth way, KGW has no added benefits. And Bitcoins hashrate is currently increasing and even if it would decrease (if marginal costs of mining outweigh the income), it would do so in a smooth way, since you won't see half the network suddenly being turned off.

What? The algorithm has been successfully implemented in several altcoins that had trouble with multi pools. It's not "pseudo science" just because it has a fancy name attached to it. It's an implementation that does its job.. what else is there to say about it really? Kimoto did a good job solving Megacoin's issues, and other devs adopted it for the same reason: it works.

I was involved with Anoncoin some time ago, and they had similar issues as Megacoin did. I suggested the dev take a look at Kimoto's solution. He did and after having a look at it decided to implement it. Problem solved. Since then others have gone the same route.

Note that I'm not saying that Bitcoin should implement it. I'm just saying it's not pseudo science, it's a solution to a problem.

pseudo-scientific gibberish by people who have no clue what they're talking about.

Please don't waste our time with things like this unless you understand it thoroughly yourself.

The hashrate shown by blockchain.info (and other websites) is not the actual network hashrate, but rather a derived quantity calculated from the time between blocks. If the network hits a streak of bad luck and only solves 3 blocks in 1.5 hours or so, this'll show on these types of graphs as a drop in the network hashrate.

In reality, I assume that the network hashrate is rather stable, with some additional power being added on constantly. A drop in true hashrate only occurs when mining hardware is switched off and outside of catastrophic outages in datacenters, I don't see that happening on a large scale.

And as long as there is no sudden, large and non-temporary drop in the hashrate, the KGW algorithm doesn't really add that much. The downside of switching difficulty algorithm is obvious: It requires a hard fork. Hard forks are a big deal. And that simply won't happen for a matter as insignificant as this.

Certainly there will be variability between block times under any scenario. However recently with the rapid increases in hashing power block times have been averaging as little as 7 minutes. This slightly accelerates the bitcoin inflation ahead of schedule. While I agree bitcoin is unlikely to have a sharp decrease in rate without recovery we are experiencing a sharp decrease right now.

https://blockchain.info/charts/hash-rate

And right after a major jump in difficulty.

https://blockchain.info/charts/difficulty

It's a better system and while it won't serve much use during constant increases in mining power nothing goes up forever, especially exponentially.

KGW won't do anything meaningful for Bitcoin. Even if the Bitcoin difficulty is adjujsted every block, there will still be periods where the average time between blocks is more than 10 minutes. Since the process of finding a block remains a Poisson process, regardless of what algorithm you use to tune the difficulty, block-delays of 30 minutes or more remain a completely real possibility.

The KGW algorithm is designed to combat a block-drought that comes from a sharply decreasing hashrate. As long as the hashrate doesn't go down rapidly, there is no real advantage to using KGW. If blocks take 11 minutes on average instead of 10 for a week or two, then that hardly matters and people won't even notice it unless they look at the data, since the variance in block-delays will obscure these structural deviations from the target average.

And since there is no reason to assume that the Bitcoin hashrate is going to sharply decrease (and not recover), there is no need to update the difficulty algorithm, which would require a hard fork.

The theory has always been that the altcoin ecosystem is a net benefit to bitcoin in part because new ideas can more easily be tried out on coins with small market caps. Then those ideas that have value can be integrated with bitcoin.

Kimoto Gravity Well is an idea that has emerged and been refined as a response to the rapid changes in difficulty various coins have experienced. Pools that hop around can leave coins stuck in a place where blocks only arrive after days of waiting, effectively killing their utility. It has always been assumed that as king of the hill that bitcoin is immune to the entire network deciding to stop hashing or go mine something else. However we're currently experiencing a moderate drop off in hashing power and blocks are taking more than 10 minutes on average. During the recent run up blocks were taking much less than 10 minutes on average.



I suggest that efforts get underway now to integrate the Kimoto Gravity Well in bitcoin before it is needed. It will help ensure consistent blocktimes which helps merchants and speculators predict the time to complete a transaction and the rate of inflation.

Here is a thread with much greater detail about KGW.