Bitcoin Forum

I finally got around to updating the my hashrate forecasts.

These new forecasts are ARIMA models of the weekly average hashrate, forecast to eight weeks in the future, and with bootstrapped and surprisingly accurate confidence intervals. the model make no reliance on the previous BTC exchange rate relationship with the network hashrate, and also do not take into account manufacturer shipping dates and amounts.

More details here: http://organofcorti.blogspot.com/2013/09/105-forecasting-network-hashrate.html

The forecasts:




The errors:



Enjoy! Post any questions you might have, but do read the blog post first - it will probably answer most of your questions.

How well does this model work when you retroactively apply it to the periods where we transitioned from CPU to GPU or FPGAs ?

I appreciate you put a lot of work in to this, but building mathematical models to make predictions that dont factor in facts like that $10M's worth of next generation hardware is due to be delivered over the next few months, makes it usability rather questionable.  Its not like charts can predict if KnC will ship all that its promised in 2 weeks or wont ship anything at all, and that alone would roughly double difficulty.

The model does well for historical increases in hashrate, even when the network hashrate increased much more rapidly in the past than it can possibly increase now, but rather poorly for abrupt decreases in hashrate (such as June 2011). Modelling the acceleration of the log of the hashrate ie diff(diff(log(hashrate))) make following upward trends more possible for the model. Of course, if someone dumps 2Phps on the network in two weeks' time then the forecast will be inaccurate. However if it take more than a week for al the machine to come online then the model should be flexible enough to respond. The percentage error will increase, though.

However I think you're missing the point of the forecasts. I'm not attempting to predict hashrate, rather to provide an indicator a bit more accurate (and well founded) than "difficulty (or hashrate) will increase by an average of 30% per month".


All good points, and as you say it's impossible to include whether a manufacturer will deliver on time and how much they will deliver. As I make clear in the post, I'm not attempting to figure that out  - that's a mugs game.

The confidence intervals are also important to pay attention to. They include historical fits to the network hashrate, which as I mentioned has already seen hashrate increases far outstripping whats happening now.

I appreciate what you're saying, but I'm pretty confident that confident that 95% of the weekly average hashrates will be inside the 95% confidence interval. However you might be right. Time will tell.

I think perhaps you do need to figure out a way to quantify the real world for inclusion in your model.

Your forecast seems to be like trying to describe the weather of Florida by taking wind and precipitation readings during a hurricane. There is value in doing this, because it does describe the hurricane, but when the hurricane ends and you start forecasting that "wind is below expectations", it doesn't mean your forecast is incorrect, it just means you are not accounting for if we are in or out of hurricane season.

We know that Moore's law predicts transistor count in a CPU and up until this year, bitcoin was not profitable enough for semiconductor manufacturers to make ASICs. Now it is profitable, so we're playing catch up, but eventually we will converge on Moore's law. If there was some way to approximate chip counts and feed it into your forecast, I think that would be very valuable. Then, you could forecast what the impact of making x chips available on the market is.

I agree. The forecast will give a better estimate of the expected hashrate increase than x% per month, but I don't know how accurate shipping forecasts are. Again, the confidence intervals are very important since they provide a degree of confidence in the forecast. They should be used as discussed in the blog post, not as a defnite prediction of the network hashrate.


I can't really do that. Regressing to data that is error prone amplifies errors, and I have no idea how accurate that sort of model would be. Think back to before the network hashrate all but decoupled from the exchange rate - would you have been able to estimate when it occurred and the effect it could have?

The new model for the data is derived each week in a way that has minimised historical errors. I expected the forecasts to under predict in the upcoming weeks, but since the confidence intervals are bootstrapped, this is taken into account. For example, you can be reasonably certain that 50% of forecasts will be within the 50% confidence interval of the network hashrate to which that forecast relates.

The best option would be to estimate shipping times and amounts, which I'd done previously - but that ended up being much more error prone than this forecast method. It all depends on how accurate the data is, and so far most manufacturers have been notoriously unreliable and vague.

Am I looking at this the wrong way or is your
eight weeks forecast off by 20% 3 days before your first week prediction?

I'm not sure what you mean. Can you rephrase your question?

Ok.

How much is your forecast off by the current numbers? :D

Which current numbers? I'm forecasting the average weekly network hashrate - that's the total hashes submitted in a week divided by 604800. The week I'm forecasting ends on the 29th.

The last seven days' average hashrate is 1150.225 Thps. So the forecast will probably be under by 20% or so.

Looks like you're saying that the difficulty factor will DOUBLE every month from now on.

How do you get that? Difficulty lags hashrate, and times between retargets change change with hashrate. Since I'm forecasting a weekly average hashrate confidence interval, I don't think you can derive an exact figure from that. I do have a nice difficulty forecast which I'll post if there's any call for it.

Even if you could, as mentioned in the blog and several times on this page, the confidence intervals for the forecast are more the important than the forecast.

To avoid confusion in future, I might just provide several confidence intervals for the forecast, and not the forecast itself. Does that sound like a good idea?

Yeah, chances seem good considering your prediction ranges between 1PH (less than today, how likely is that) and >12PH
I dont even have to look at a weather map to be able to predict tomorrow temperatures will be between -20C and +40C with 95% confidence.

No. The next forecast was for 1152 Thps with a 95% confidence interval of -17% to +21%. That's about 956 to 1393 Thps. How on earth did you calculate your values?

And yes, the forecast is lower than the current seven day average by about 50Ghps. So?

I think it's very likely it will be within the 95% confidence interval. and possible it will be within the 50% confidence interval





You still don't really understand how forecasting works. :(

Temperature is a stationary time series. The network hashrate is not. If the temperature was exponentially increasing per day, and I could forecast the next day's temperature within +/- 20% with 95% confidence, I'd be quite happy with that.





Or confidence intervals.

Firstly, in this context they indicate the probability of a given occurrence. This means they show the uncertainty associated with a given forecast. How many other estimates of future hashrates provide a confidence interval for their estimate that not just made up?

So if you know a given forecast only provides accuracy that is too poor for your purposes, why would you use it? Or even comment on it?

Im looking at the 2 month ahead prediction: 3548TH -71% +251%
-71% means -2519 so 1028 TH correct?
+251% means +8905 = 12453 TH

Sorry if I misunderstood that.


Not that I dont appreciate it, but I guess Im curious why you would spend so much time calculating it, or  for what  purposes such a wide range would be accurate enough?

No, the eight week forecast interval is extremely wide. Part of the reason for this is that the network hashrate is increasing exponentially, so the confidence intervals are the exponential of the modelled confidence intervals. I wasn't sure I should include anything after the first four weeks, but I thought readers might find it interesting to see how it becomes harder to accurately estimate the network hashrate into the future. A tiny change the percentage rate of change now can make peta-hashes of difference a couple of months from now.


Getting an accurate and reliable model is the hard part. Once you have that, the forecasts follow. I could provide forecasts of the hashrate a billion years from now, if you want. It would have a fairly wide confidence interval though.


Although they only directly apply to the model, I think these confidence intervals should also give you an idea of how much confidence to place in anyones estimate of the hashrate months from now.  If someone estimates that the hashrate will increase by thirty percent per month for the next four months then they're probably going to be subject to a much larger confidence interval for the hashrate. Exponential changes in the hashrate mean exponential errors, and I think it's something that people don't generally take into account.

So the point of the exercise is demonstrating just how pointless the exercise is :p
/tongue-in-cheek.

Excellent work in my opinion, I've been looking at length for such kind of research. Satoshi sent to support your site.
Would you consider performing ARIMA analysis on BTC price?

I've done that, along with an exponential smooth. The confidence intervals make it a very rough guide. I'll get around to posting something when I have time. Or after I've made my millions first, heh. From memory I think a random walk + drift model based on ~ the last three months was as good as the ETS model.

Since I've lately been working on working out "Gambler's Ruin" in brownian motion, this got me to thinking that a brownian motion model might be fun to try. Rather than forecasts I'd be able to plot times of first passage (eg time to 150 usd/btc, 160 usd/btc etc) with confidence intervals - sort of a reverse forecast since the result would be times rather than prices. If I do get some time, I'll post the results. Even if it's not very accurate, it would be very cool.

Thanks for sharing this. Quite interesting.

Are you planning on also publishing the equivalent in the Difficulty rate?
If not, would it be difficult to do that or ?

I ask because I'm looking for some new difficulty predictors. Any suggestions?

Thx,
IAS

I've already done this, just haven't gotten around to posting. Explaining what I'm doing takes way longer than actually doing it, and if I don't do a good job in the explanation then I get responses such as those at the top.

As for difficulty predictors, it depends on what you want. If you want something more than 4 retargets ahead, then you're better off checking out Death and Taxes' thread (https://bitcointalk.org/index.php?topic=283820.0).

I'm just looking for a difficult predictor to compliment what is already out there. It seems you are taking the hashing projections quite deep and so you probably will have one of the more accurate difficulty predictors. As far as timeline, it would be nice to have a 4 week projection. But what you are already doing with the range can allow you to take it out further (but perhaps that doesn't serve a real useful purpose so far out). That range (leeway with your blue shadows looking forward) is great.

Thanks for the quick reply btw,
IAS

Organ, may I suggest an analysis that I personally would find more interesting?
Not sure how to put it, but giving us an idea of how accurate live updating difficulty predictions and hashrate estimates are.

For instance, right now, when I visit
http://dot-bit.org/tools/nextDifficulty.php

I see a projection of 235M, but its based on ~600 blocks. What is the spread on that ?

Or put another way, I would like to see something similar as dot bit, but guessing *current* network hashrate and next difficulty adjustment with 50 and 95% confidence intervals.

This would have to be live updating to be really interesting tough.

ooc, can you translate your next forecast into bitcoin mining difficulty numbers? Like, 200 million, 300 million, 500 million, 1 billion, ... and when we can expect this?

Worst case scenario when all the new hardware comes online and hashing (this company said 2000 TH by January 2014, that company said 1000 TH, etc.)

I didn't see that before and wondered who donated. Thanks for that!

Thanks for all your input, Its About Sharing, Puppet and Dabs. You've all given me some idea of interesting problems to work on. Sorry it's taken so long for me to get back to you.


The I can forecast four retargets (~ 6 weeks at the moment) ahead with reasonable accuracy, better than the 6 week average hashrate forecast anyway. I'll post here once I get a post up. I really do want to get the forecasts up weekly but finding the time is tricky.

Puppet's comment addresses a way around the posting problem:


Live updating would be fantastic. I have a domain, and I could easily write something automated to regenerate charts at a two hour lag (to allow for orphaned blocks) but I have two problems:

 * I have absolutely no experience in running or coding a site or a server
 * Not many hosts are ok with their server running bitcoind - I remember one guy who was kicked off his host for exactly that (I think they thought he was mining or something)

So I could do (and already do for myself) exactly what you're suggesting but I have no idea how to do it or even how to go about learning to do it, or if I have enough time to learn to do it. I'd welcome any hints or suggestions.


I actually do a separate model for Difficulty - it's more accurate than estimating based on an estimated hashrate, and also forecasts the date of the difficulty change too.

The model can't do a worst case scenario though, and forecasting that far ahead would be too inaccurate by any measure of use. Death and Taxes' thread (https://bitcointalk.org/index.php?topic=283820.0) is what you're after. A visualisation of the data in that thread is probably a good idea and I can do that - but it won't be a modelled forecast with confidence intervals and so forth.

I promise I'll get around to posting forecasts weekly (weekly average hashrate, daily average hashrate and difficulty) but I'm really focussed on forecasting BTC prices. I didn't think it could be done with any degree of usefulness, but as I learn and experiment more I'm finding out I was wrong. It's really exciting (if you're in to that sort of thing).

You dont have to run a local bitcoind, you could just use blockchain.info's api:
http://blockchain.info/api/json_rpc_api

I didn't think of getting a blockchain account and using the api - that's a great idea, and reading the api it looks like it would be pretty easy to implement. Now I just have to work on the first of the two problems :(

Id offer my help, but my PHP skills are really not very good. Perhaps you can team up with one of the sites that currently publish similar information, like thegenesisblock, blockchain.info or even futureblock.

Again, that never occurred to me. It does sound like the best way to go about it.

Can I make a suggestion? Start a thread called "cool bitcoin shit I know" which I for one would find very helpful.

Futureblock is interesting. I think I'd use my skills for evil and bet, although the 20% house fee is a bit off-putting.

20% fee is only if you bet at the tail end of the betting window. If you place your bet in the beginning, its 0.
I love the idea of that site, but I just wish the subject of the bet wouldnt be someone else's ambiguous estimate of network hashrate, but something unambiguous like difficulty, number of blocks found, etc.

organofcorti,

A thought - do you have enough information from the pools to be able to specify average GH/s per user account and get a total # of user accounts? I think if you compared that to hardware available at the time (in terms of either GH/s/$ or GH/s/W), you could perhaps determine a relationship between available GH/s/[$,W] and GH/s/user. Making the assumption that most people have a fixed amount of power/income they can provide to this effort, it might show how future changes to efficiency/pricing can impact total network hashrate. I think that would yield more accurate results than basing it on historical information.

Also, re: your other comments, I do know PHP fairly well and have a Linode that I'd be happy to host with. PM me if you're interested and we can put something together.

I've got the user hashrate distribution data which I update each week. However the average is not a very good indicator, and neither is the median. The hashrates per user account are generally pareto distributed, often with and undefined mean.

Secondly, I only have data for about half the network. When I had about 75% of the network I could extrapolate to the rest of the network. Now, it's just too inaccurate.

The last post I did on the subject was: http://organofcorti.blogspot.com/2013/07/network-electricity-consumption-16th.html


Thanks for the offer - PM sent.

omg please continue to report on that information, I think that is VERY useful data.

I will at some point - just need things to settle down a bit first.