Over the past several months I have had a number of conversations with Dave Hudson, proprietor of HashingIt.com; some of these quotes ended up in the book.  A couple months ago he became the VP of software development over at PeerNova; he also has a strong background in both chip design and network graph analysis.

Last week he gave a presentation at the Bitcoin Dev meetup in San Francisco (special thanks to Taariq Lewis for hosting it) where he explains, in minute detail, how to differentiate between noise and signal when analyzing changes in hash rate.

The deck of the presentation is here.  I think his discussion covered on slides 26-30 provide a very cogent argument for what I discussed on page 32; if I update the book I’ll be sure to include his analysis because it is the most probably explanation.

I highly recommend the entire hour long lecture because it is probably the best single source of non-partisan analysis of what mining as a statistical process looks like and why it has evolved to look the way it does today (especially around 43:00m regarding incentives for pooled mining).  His proposed solution, by staggering a hard fork over a period of time to increase block confirmation times by 5x is also interesting because it looks like it may be incentive compatible for current miners, farms and pools to implement.

Below are some transcribed portions starting around 12:00m regarding an explanation for hash rate estimations (slide 26 and 27):

So the other thing that is interesting of course about a logarithmic plot is that if you actually plot a straight line on a logarithmic plot you can actually see if you are seeing an exponential expansion.  There was a period of time where that was almost a straight line.  In fact if you look at the statistics from the end of last year and the early part of this year it was pretty much a straight line; we were seeing a straight logarithmic expansion.  But now in fact, that is slowing down, so in fact there is actual slow down in the hash rate.  And that is likely to continue until there is a significant change in the technology of that is implementing the hashing.

So we’ve reached the limit pretty much in terms of process technology for ASICs.  There are a couple of nodes left that, I have not talked about it in this but there is some stuff on the blog.  We are in 28 nanometers now there is some room to go in 28nm but it is not a huge amount.  The reality is we can get to state-of-the-art around 14 to 16 nanometers and then we are just waiting on the fabs to be able to move to something better than that.  So the amount that we can actually gain from just process technology is diminishing significantly.

The other problem is that from a power efficiency perspective, the power efficiency just doesn’t improving at the same rate it was before.  When you can jump and leverage many years of the process improvements in the course of one generation of ASICs and go from 130 to 65 to 28 then you can see dramatic improvements and dramatic improvements in the power efficiency.  That’s just not possible when you start getting out to 28.  So yes, you can put more capacity online but the amount of power that it is likely to take will go up much more dramatically then what we’ve seen in previous generations.  So this is leading to a slow down.

The other thing of course is you can look at the block mining reward and say ‘well most of the funding for this sort of hash rate expansion has to come from the block mining rewards.’  And given that there isn’t a massive spike in bitcoin price which is driving the ability to pay for more hardware then you’re not going to see those sorts of huge increases.  There is certainly the capacity to do that, if the price of bitcoin were to go up by a factor of 5 then there is a lot more money available for people to throw at hardware and throw at operational costs.  So there is scope for that.  But while things are actually relatively static then things are going to slow down, so we’ll see some slow down.