8th June 2013
0. Introduction
In April a number of news sites reported an estimate of the network's electricity use. The reports were poorly researched and all used data from blockchain.info. None of the journalists applied any of their own research or attempted to find other sources that might help indicate estimate how inaccurate this estimate is.
This post is an attempt to make a more accurate estimate of the current electricity usage of miners in securing the network. Since some data cannot easily be estimated it may be inaccurate and the only guarantee I give is that the estimate I calculate is more accurate than the blockchain.info estimate. This post should be considered a "Proof of concept".
In order to make a better estimate, data will be needed from miners directly. I've made a survey which I'll introduce later and which I hope many of you will take a few minutes to complete.
It should be noted that this post only estimates the electricity cost of securing the network - it does not include the cost of nodes or wallets.
We can make a quick and dirty estimate of the upper bound of the network's electricity use if we make a number of assumptions.
Assumption 1: Assume on average that miners will make a profit.
Assumption 2: 144 blocks per day are solved ( although it's quite a bit more at the moment ).
Assumption 3: Average electricity cost is US$0.15 per kWh
At the current price of $122 per BTC total income per day is US$439, 200, so on average miners would only make a profit if the estimated electricity cost is below that figure. At US$0.15 per kWh US$439, 200 would be 2928000 kWh per day, or 122 MW.
Another quick and dirty estimate of the upper bound can be made by assuming that all miners use a GPU that has an efficiency of 0.65 J per Mh. At the current network hashrate estimate of 120 Thps, this equates to 78 MW.
How accurate are these estimates? Not very.
1. How efficient are the various types of mining?
The bitcoin wikipedia has a page that answers this question in detail. Using the data that has been collected there, the relationship between joules per Mhash and Mhash per second for each device can analysed and modelled:
For CPUs and GPUs there is a log-log relationship between JpMh and Mhps - they tend to become more efficient at higher hashrates. For FPGAs and ASICs ASICS, the relationship is almost linear - efficiency only varies a little. In the plot below the lines are estimated using the above models for CPUs, and GPUs. For FPGAs and ASICs I've used the median efficiency for each group.
2.0 Applying mining tool efficiencies to raw hashrate per user data.
This is where a number of assumptions and estimates need to be made. The first four I expect to be fairly accurate:
Assumption 1: CPU mining is responsible for hashrate less than 0.05 Ghps
Assumption 1: CPU mining is responsible for hashrate less than 0.05 Ghps
Assumption 2: NVidia GPU mining is responsible for hashrate less than 0.15 Ghps and greater than or equal to 0.05 Ghps.
Assumption 3: ASICs are responsible for any hashrate greater than 211 Ghps (the maximum
pre-ASIC hashrate I recorded was ~ 211 Ghps).
However from 0.15 Ghps to 220 Ghps there will be a mix of:
and any combination of these. I expect very few people have only 0.1 Ghps of FPGA hashing, so starting this group from 0.15 Ghps will not affect accuracy significantly.
Next, an estimate of the increase over time of the number of users with ASIC hashrates in the range 0.3 to 211 Ghps has to be estimated.
2.1 Estimating the number of ASICs
In previous posts I've shown how to use a number of pools combined user hashrates to estimate the number of users in various hashrate bins and the total amount of hashrate contributed by them. If we assume that there is a certain percentage increase in the number of users for a given hashrate bin that is attributable to AMD GPUs and FPGAs, then any increase in user numbers above this is the result of users with ASICs.
In the first chart below, each plot shows the percentage increase in the number of users in a particular hashrate bin over time. Data is interpolated between known dates by weighting by hashrate and comparing the sum to the known network hashrate. This provides and estimate of how large a proportion of the network the sample is.
Assumption 5: Binned user counts in the sample are a good estimate for the network binned user counts, and the total network user counts can be estimated multiplying the count data by [network hashrate] / [total sample hashrate].
The colours in the first plot represent the following bins:
Red: 0 to 0.15 Ghps
Green: 0.16 to 0.25 Ghps
Blue: 0.26 to 0.5 Ghps
Purple: 0.51 to 0.75 Ghps
For the second plot the colours represent the following bins:
Red: 0.76 to 1.00 Ghps
Green: 1.01 to 1.25 Ghps
Blue: 1.26 to 1.5 Ghps
Purple: 1.51 to 1.75 Ghps
The remainder of the plots are similarly coloured.
The "waviness" and the stepped discontinuities of the lines are both due to the interpolation method used.
Most of the bins show a large spike in late April - just after the peak and fall in the BTC price, when media reports were at their highest. The biggest increase was in the 0 to 0.15 Ghps range, but all the hashrates that could be accounted for by one CPU or one GPU (the first plot) show a similar increase. Even at hashrates that would require multiple cards, this peak is evident. Most of the new users have left by the next week, but a slow gradual increase of about 150% to 200% is present by June 2nd (the last data point).
Assumption 6.1: The number of users with hashrates up to 0.25 Ghps that used two or more pools during the time a pool's hashrate was estimated is negligible, and;
Assumption 6.2: Variance in hashrate is also negligible.
The last two assumptions allow us to assume that the 0 to 0.15 Ghps and 0.16 to 0.25 Ghps bins (red and green in the first plot) are unlikely to have any ASIC users included since there are none produced with hashrates that small.
Since all the bins show similar increases to those first two bins, we can assume that the number of ASIC users added in each bin is negligible compared to the total number of users in that bin.
Summary: There have been a negligible number of ASICs added at user hashrates up to 6 Ghps .
The next chart visualises data in the same way as the chart above, for hashrates in 3 Ghps bins, from 6 Ghps to 39 Ghps.
The changes in the bins in the first two plots are similar to those in the last chart, allowing for some variance due to the smaller number of users in each bin. However in the last plot we find the first data that shows an unusual increase in the number of users. The 33.1 to 36 Ghps bin records an increase of about 350% by April 14th (the first post ASIC non-interpolated data point) and a total 500% until June 2nd. This seems about right for it to be an Avalon ASIC, but the hashrate is too small - in fact about 50% too small. We'll come back to this later, with other interesting data.
Next, 10 Ghps bins from 39 to 119 Ghps.
The second plot contains the interesting data here, the increase in user count likely from Avalon ASICs.
The 69 to 79 Ghps bin especially follows the known shipping times of batch one and two form Avalon quite nicely.
Finally, user hashrates from 119 Ghps to 218 Ghps in 33 Ghps bins.
By this point, bins which include an integer multiple of the ~ 70 Ghps Avalon hashrate should be expected. The middle bin which does not contain such in integer multiple shows a ~ 250% increase by June 2nd consistent with the increases of the non-ASIC bins.
pre-ASIC hashrate I recorded was ~ 211 Ghps).
However from 0.15 Ghps to 220 Ghps there will be a mix of:
- AMD GPUs from 0.15 Ghps (5770) to 0.65 Ghps (7990)
- FPGAs from 0.1 Ghps (Bitcoin Dominator X5000) to 25 Ghps (Butterflylabs Mini Rig)
- ASICs from 0.3 Ghps (ASICMiner USB miner) to 65 Ghps (Avalon)
and any combination of these. I expect very few people have only 0.1 Ghps of FPGA hashing, so starting this group from 0.15 Ghps will not affect accuracy significantly.
Next, an estimate of the increase over time of the number of users with ASIC hashrates in the range 0.3 to 211 Ghps has to be estimated.
2.1 Estimating the number of ASICs
In previous posts I've shown how to use a number of pools combined user hashrates to estimate the number of users in various hashrate bins and the total amount of hashrate contributed by them. If we assume that there is a certain percentage increase in the number of users for a given hashrate bin that is attributable to AMD GPUs and FPGAs, then any increase in user numbers above this is the result of users with ASICs.
In the first chart below, each plot shows the percentage increase in the number of users in a particular hashrate bin over time. Data is interpolated between known dates by weighting by hashrate and comparing the sum to the known network hashrate. This provides and estimate of how large a proportion of the network the sample is.
Assumption 5: Binned user counts in the sample are a good estimate for the network binned user counts, and the total network user counts can be estimated multiplying the count data by [network hashrate] / [total sample hashrate].
The colours in the first plot represent the following bins:
Red: 0 to 0.15 Ghps
Green: 0.16 to 0.25 Ghps
Blue: 0.26 to 0.5 Ghps
Purple: 0.51 to 0.75 Ghps
For the second plot the colours represent the following bins:
Red: 0.76 to 1.00 Ghps
Green: 1.01 to 1.25 Ghps
Blue: 1.26 to 1.5 Ghps
Purple: 1.51 to 1.75 Ghps
The remainder of the plots are similarly coloured.
The "waviness" and the stepped discontinuities of the lines are both due to the interpolation method used.
Most of the bins show a large spike in late April - just after the peak and fall in the BTC price, when media reports were at their highest. The biggest increase was in the 0 to 0.15 Ghps range, but all the hashrates that could be accounted for by one CPU or one GPU (the first plot) show a similar increase. Even at hashrates that would require multiple cards, this peak is evident. Most of the new users have left by the next week, but a slow gradual increase of about 150% to 200% is present by June 2nd (the last data point).
Assumption 6.1: The number of users with hashrates up to 0.25 Ghps that used two or more pools during the time a pool's hashrate was estimated is negligible, and;
Assumption 6.2: Variance in hashrate is also negligible.
The last two assumptions allow us to assume that the 0 to 0.15 Ghps and 0.16 to 0.25 Ghps bins (red and green in the first plot) are unlikely to have any ASIC users included since there are none produced with hashrates that small.
Since all the bins show similar increases to those first two bins, we can assume that the number of ASIC users added in each bin is negligible compared to the total number of users in that bin.
Summary: There have been a negligible number of ASICs added at user hashrates up to 6 Ghps .
The next chart visualises data in the same way as the chart above, for hashrates in 3 Ghps bins, from 6 Ghps to 39 Ghps.
The changes in the bins in the first two plots are similar to those in the last chart, allowing for some variance due to the smaller number of users in each bin. However in the last plot we find the first data that shows an unusual increase in the number of users. The 33.1 to 36 Ghps bin records an increase of about 350% by April 14th (the first post ASIC non-interpolated data point) and a total 500% until June 2nd. This seems about right for it to be an Avalon ASIC, but the hashrate is too small - in fact about 50% too small. We'll come back to this later, with other interesting data.
Next, 10 Ghps bins from 39 to 119 Ghps.
The second plot contains the interesting data here, the increase in user count likely from Avalon ASICs.
The 69 to 79 Ghps bin especially follows the known shipping times of batch one and two form Avalon quite nicely.
Finally, user hashrates from 119 Ghps to 218 Ghps in 33 Ghps bins.
By this point, bins which include an integer multiple of the ~ 70 Ghps Avalon hashrate should be expected. The middle bin which does not contain such in integer multiple shows a ~ 250% increase by June 2nd consistent with the increases of the non-ASIC bins.
Next are some tables of the user counts of some of the more interesting user hashrate bins. It should be noted that as the estimated count approaches 1, results will be more influenced by sample variance. The final column "Estimated number of ASICs", indicates the number of users who are providing hashes from ASIC devices, not the number of ASIC devices they have.
In the third chart of this section the 33.1 to 36 Ghps bin looked interesting. The previous bins did not appear to have any significant increase in user count, so I'm assuming that a negligible number of them have ASICs. To remove the non-ASIC users from the 33.1 to 36 Ghps bin, I've summed the previous non ASIC bin user counts and calculated the percentage of the initial hashrate in January:
33.1 to 36 Ghps bin count minus [the initial 33.1 to 36 Ghps bin count multiplied by the estimated percentage increase of the non-ASIC count] should give an indication of how much of the 33.1 to 36 Ghps contains ASIC users:
In the fourth chart of this section the 59.1 to 69, 69.1 to 79 and 79.1 to 89 Ghps bins looked interesting. As for the 33.1 to 36 Ghps bin, I've summed the previous non ASIC bin user counts and calculated the percentage of the initial hashrate in January:
The total 59.1 to 89 Ghps bins count minus [the initial 59.1 to 89 Ghps bins count multiplied by the estimated percentage increase of the non-ASIC count] :
In the fifth chart of this section all the bins looked interesting. Again, I've summed the previous non ASIC bin user counts and calculated the percentage of the initial hashrate in January:
The total 59.1 to 89 Ghps bins count minus [the initial 119.1 to 218 Ghps bins count multiplied by the estimated percentage increase of the non-ASIC count] :
This is not a very good estimate based on known data, even allowing for "luck" due to high difficulty shares, the possibility that a pool with a larger than average percentage of ASICs is missing from that data, and an unknown number of solo miners. If we discount the "increase in non-ASIC users", then the following estimates result:
This is a little better. I'm inclined to believe there has been no significant increase in non-ASIC users from user hashrates of 6 Ghps and up, due to the latter analysis and also by considering the onset times of the increases in these groups. Difficulty was increasing, the btc price was not increasing significantly, and at the same time ASICMiner blades became available. I think it is much more likely that these increases are due to ASIC mining tools rather than new GPU / FPGA tools.
Assumption 7: Any increase in user counts (and hence overall hashrates) for user accounts greater than 6 Ghps is solely due to ASIC mining tools.
2.2 Estimating the proportion of GPUs and FPGAs
The last section was at least amenable to analysis (albeit one relying on a number of assumptions). This section is not. Instead, I've made the following assumption:
Assumption 8: Big professional farms will be mostly FPGA, and smaller home based farms will be mostly AMD GPUs.
I'm basing this on the fact that one can purchase a number of GPUs and risk very little - resale value will be high since GPUs can be used for other purposes.
However, if you're making a business of bitcoin mining, then you are already long in btc, and the fact that FPGAs would be unlikely to be able to be repurposed in the even of a massive crash in btc price. Further, most people started GPU mining before FPGA mining. The choice of purchasing an FPGA - especially the BFL 25 Ghps rigs - was an expensive one necessitating a business plan.
This limits smaller home based farms to 10 - 20 Ghps, depending on your home amperage, voltage and power factor and assuming no access to three phase power.
Secondly, the user count shows a significant drop after the 6.1 to 9 Ghps bin:
While I realise there will be a mix of FPGAs and GPUs in hashrate bins, I can't really estimate that mix. So, instead I'm assuming GPUs are responsible for all hashrates less than or equal to 20 Ghps and FPGAs are responsible for all hashrates greater than 20 Ghps.
Assumption 9: GPUs are responsible for all hashrates less than or equal to 20 Ghps and FPGAs are responsible for all hashrates greater than 20 Ghps.
2.3 Estimating the energy cost of mining.
Hashrates less than or equal to 0.05 Ghps:
Hashrate x exp(3.99 + log(Hashrate*1000) x -0.73)
Hashrates less than or equal to 0.15 Ghps and greater than 0.05 Ghps:
Hashrate x exp(2.73 + log(Hashrate*1000) x -0.44)
Hashrate x exp(1.89 + log(Hashrate*1000) x -0.44) for up to 650 Mhps, then cycling through the 150 Mhps to 650 Mhps for multiple GPUs.
Hashrates less than or equal to 20 Ghps and greater than 0.3 Ghps:
Hashrate @ at 27th January x exp(1.89 + log(Hashrate*1000) x -0.44) for up to 650 Mhps, then cycling through the 150 Mhps to 650 Mhps for multiple GPUs plus the difference in hashrate x 1000 x median ASIC efficiency, 0.0098 joules per Mhash.
Hashrate @ at 27th January x 1000 x median FPGA efficiency, 0.0502 joules per Mhash, plus the difference in hashrate x median ASIC efficiency, 0.009803922 joules per hash.
This will be a good estimate for now, but as more GPUs leave, it will be much less accurate.
Finally, the last plot shows the estimated user hashrate, counts, and electricity use in various hashrate bins, and of course the estimated network totals for hashrate, number of users and electricity use.
3. Summary
Main points:
4. Survey time!
It's quite possible to make the network electricity use estimate much more accurate, and that's with a survey of miners.
I've posted a survey which I invite all miners to complete. If I can get a large number of respondents I'll be able to use this data to produce a more accurate estimate with fewer assumptions. I get about ten thousand unique visits per month, so I hope some of you who are miners would like to help out.
The survey itself looks a bit long and daunting, but most miners will only have to answer ten questions or less, and it should take less than ten minutes. I'll make the data publicly available to whomever wants it.
Note that I've asked for your electricity cost in US$ per kWh. I apologise for having to use one currency (which I myself don't even use) but trying to convert from a number of different currencies to US$ based on the day of the response was going to be a headache. I hope non-US citizens understand.
The survey: click here
Thanks for your help!
Main points:
- Network electricity use is governed mainly by users with hashrates up to 20 Ghps
- At 10 MW and an estimated average electricity cost of US$ 0.15 per kWh, the cost per day of securing the network is US$36000 - not hundreds of thousands of dollars per day, as new sites estimated.
Also:
- We have an estimated 30000 user accounts in the network
- The network has doubled in hashrate since April 14th, but the total electricity use has increased by only a third.
- A large number of CPU and GPU miners came and went in April - and had no significant effect on the hashrate, but a very large effect on the total electricity use.
4. Survey time!
It's quite possible to make the network electricity use estimate much more accurate, and that's with a survey of miners.
I've posted a survey which I invite all miners to complete. If I can get a large number of respondents I'll be able to use this data to produce a more accurate estimate with fewer assumptions. I get about ten thousand unique visits per month, so I hope some of you who are miners would like to help out.
The survey itself looks a bit long and daunting, but most miners will only have to answer ten questions or less, and it should take less than ten minutes. I'll make the data publicly available to whomever wants it.
Note that I've asked for your electricity cost in US$ per kWh. I apologise for having to use one currency (which I myself don't even use) but trying to convert from a number of different currencies to US$ based on the day of the response was going to be a headache. I hope non-US citizens understand.
The survey: click here
Thanks for your help!
organofcorti.blogspot.com is a reader supported blog
BTC: 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
LTC: LPXnETNoCBr16GduvyWRzFP83rZNeEgMuB
No comments:
Post a Comment
Comments are switched off until the current spam storm ends.