mrb's blog

Electricity consumption of Bitcoin: a market-based and technical analysis

Keywords: mining asic energy efficiency

I drew a chart juxtaposing the Bitcoin hash rate with the market availability of mining ASICs and their energy efficiency. This allows calculating with certainty the lower and upper bounds for the global electricity consumption of miners. I decided to do this research after seeing that so many other analyses were flawed. See for example the flagrant errors in Digiconomist’s Bitcoin Energy Consumption Index. I believe that my market-based and technical approach is superior and more accurate.

[Edit: this post was also published in Bitcoin Magazine.]

I split the timeline in 10 phases representing the releases and discontinuances of mining ASICs. See the references and a commentary on the data behind this chart:

Hash rate and mining ASICs efficiency

I reached out to some Bitcoin ASIC manufacturers when doing this market research. Canaan was very open and transparent (thank you!) and gave me one additional extremely useful data point: they manufactured a total of 191 PH/s of A3218 ASICs.1

Determining the upper bound for the electricity consumption is then easily done by making two worst-case assumptions. Firstly we assume that 100% of the mining power added during each phase came from the least efficient hardware available at that time that is still mining profitably.2 Furthermore, despite A3218 being the least efficient in phases 5-8 we can only assume 191 PH/s of it were deployed, and the rest of the hash rate came from the second least efficient ASIC:

  • Phase 0: 290 PH/s @ 0.51 J/GH (BM1384)3
  • Phases 1-3: 150 PH/s @ 0.51 J/GH (BM1384)
  • Phase 4: 40 PH/s @ 0.25 J/GH (BM1385)
  • Phase 5: 191 PH/s @ 0.29 J/GH (A3218) +
    159 PH/s @ 0.25 J/GH (BM1385)
  • Phase 6: 670 PH/s @ 0.25 J/GH (BM1385)
  • Phase 7: 350 PH/s @ 0.20 J/GH (Bitfury 28nm)
  • Phase 8: 150 PH/s @ 0.13 J/GH (BF8162C16)
  • Phase 9: 1250 PH/s @ 0.15 J/GH (A3212)
  • Average weighted by PH/s: 0.238 J/GH

Secondly we assume none of this mining power, some of it being barely profitable, was ever upgraded to more efficient hardware.

Therefore the upper bound electricity consumption of the network at 3250 PH/s assuming the worst-case scenario of miners deploying the least efficient hardware of their time (0.238 J/GH in average) is 774 MW or 6.78 TWh/year.

Now, what about a lower bound estimate? We start with a few observations about the latest 4 most efficient ASICs:

  • Bitfury BF8162C16’s efficiency can be as low as 0.06 J/GH. But the clock and voltage configuration can be set to favor speed over energy efficiency. All known third party BF8162C16-based miner designs favor speed at 0.13 J/GH (1, 2). Bitfury’s own private data centers also favor speed with their immersion cooling technology (1, 2, 3). The company once advertised the BlockBox container achieved 0.13 J/GH (2 MW for 16 PH/s), presumably close to the efficiency achieved by their data centers. But we want to calculate a lower bound, so let’s assume the average BF8162C16 deployed in the wild operates at 0.10 J/GH.
  • KnCMiner Solar is exclusively deployed in their private data centers and achieves an efficiency of 0.07 J/GH.
  • Bitmain BM1387’s efficiency is 0.10 J/GH.
  • Canaan A3212’s efficiency is 0.15 J/GH.

As to market share, we know KnCMiner declared bankruptcy and was later acquired by GoGreenLight. They currently account for 0.3% of the global hash rate… a rounding error we can ignore.

Therefore the lower bound electricity consumption of the network at 3250 PH/s assuming the best-case scenario of 100% of miners currently running one of the latest 3 most efficient ASICs (at best 0.10 J/GH) is 325 MW or 2.85 TWh/year.

Can we do better than merely calculating lower and upper bounds? I think so, but with the exception of Canaan,1 other mining hardware manufacturers tend to be secretive about their market share, so anything below are just educated guesses…

Virtually all of the 1750 PH/s added after June 2016 came from BF8162C16, BM1387, and A3212, with the latter having the smallest market share. So the average efficiency of this added hash rate is likely around 0.11-0.13 J/GH. This represents 190-230 MW.

I would further venture that out of the 1500 PH/s existing as of June 2016, perhaps half was upgraded to BF8162C16/BM1387/A3212, while the other half remains a mixture of BM1385 and A3218. This represent 750 PH/s at 0.11-0.13 J/GH, and 750 PH/s at 0.26-0.28 J/GH, or a total of 280-310 MW.

I believe an insignificant proportion of the hash rate (less than 5%?) comes from all other generations of ASICs. Bitfury BF864C55 and 28nm deployments were upgraded to BF8162C16. KnCMiner/GoGreenLight represents 0.3%. BM1384 is close to being unprofitable. RockerBox, A3222, Neptune have long been unprofitable.

Therefore my best educated guess for the electricity consumption of the network at 3250 PH/s adds up to 470-540 MW or 4.12-4.73 TWh/year.

Economics of mining

Given the apparent high energy-efficiency, hence relatively small percentage of mining income that one needs to spend on electricity to cover the operating costs of an ASIC miner, it may seem that mining is an extremely profitable risk-free venture, right?

Not necessarily. Though mining can be quite profitable, in reality it depends mostly on (1) luck about when BTC gains in value and (2) timing of how early a given model of mining machine is put online (compared to other competing miners deploying the same machines.) I say this as founder of mining ASIC integrator TAV, as an investor who deployed over time $250k+ of GPUs, FPGAs, and ASICs, and as someone who once drove 2000+ miles to transport his GPU farm to East Wenatchee, Washington State in 2011 in order to exploit the nation’s cheapest electricity at $0.021/kWh—yes it was worth it!

To demonstrate the real-world profitability of a miner, I modeled the income and costs generated by an Antminer S5 batch 1 ($418, 590 W, 1155 GH/s, released on 27 December 2014) assuming mined bitcoins are sold on a daily basis at the Coindesk BPI, and assuming $0.05/kWh. See income-antminer-s5.csv:

  • On 27 December 2014 (day 1) mining starts; 15% of the first day’s mining revenues ($0.71 out of $4.64) is spent on electricity, generating an income of $3.93.
  • On 15 January 2016 (day 385) $854 of income has been generated (84% of the lifetime income); 39% of the daily mining revenues ($0.71 out of $1.84) are being spent on electricity.
  • On 15 July 2016 (day 567) $1013 of income has been generated (99% of the lifetime income); 78% of the daily mining revenues ($0.71 out of $0.90) are being spent on electricity.
  • On 8 October 2016 (day 652) $1021 of income has been generated (lifetime income); the daily mining revenues become insufficient to cover electricity costs. This day is economically and rationally the end-of-life of the S5. Past this point, mining is unwise or at best futile: either very small amounts of money will be made, or large amounts will be lost, depending on day-to-day BTC price fluctuations.
  • On 15 March 2017 (day 810) if the miner had continued mining, the total income actually manages to reach $1030. This represents $0.06 gained every day beyond day 652. Futile indeed.

The lifetime electricity costs are $0.71 × 652 = $463. The lifetime mining revenues are $463 + $1021 = $1484. A miner who had invested $418 into purchasing an S5 would have, after deducting electricity costs, turned it into $1021, a 2.4× gain. So mining was quite profitable!4

An S5 mined $1484 over its lifetime:

  • 31% ($463) recoups electrical costs
  • 28% ($418) recoups the hardware cost
  • 41% ($603) are potential profits but a part of them are needed to recoup other expenditures: data center, labor, etc

I also modeled other miners:

Antminer S7 batch 1 ($1823, 1210 W, 4860 GH/s, released on 13 October 2015) in income-antminer-s7.csv. As of 15 May 2017 the S7 continues to be profitable, has operated for 581 days, and has mined $3323 ($842 electricity + $2481 income). Out of $3323 mined by the S7:

  • 25% ($842) recoups electrical costs
  • 55% ($1823) recoups the hardware cost
  • 20% ($658) are potential profits

Antminer S9 batch 1 ($2100, 1375 W, 14.0 TH/s, released on 12 June 2016) in income-antminer-s9.csv. As of 15 May 2017 the S9 continues to be profitable, has operated for 338 days, and has mined $3531 ($558 electricity + $2973 income). Out of $3531 mined by the S9:

  • 16% ($558) recoups electrical costs
  • 59% ($2100) recoups the hardware cost
  • 25% ($873) are potential profits

Canaan Avalon 4 ($?, 680 W, 1.0 TH/s, released on 12 September 2014) in income-avalon4.csv. Its last profitable day was 8 July 2016 (666 days of operation). It spent 31% of its total mining revenues to recoup electricity.

Canaan Avalon 6 ($1100, 1000 W, 3.5 TH/s, released on 21 November 2015) in income-avalon6.csv. As of 15 May 2017 it continues to be profitable, and has operated for 542 days. So far it has spent 32% of its total mining revenues to recoup electricity.

Canaan Avalon 721 ($888, 900 W, 6.0 TH/s, released on 21 November 2016) in income-avalon721.csv. As of 15 May 2017 it continues to be profitable, and has operated for 176 days. So far it has spent 28% of its total mining revenues to recoup electricity.

Bitfury BF864C55 (comes in different configurations, model assumes a 0.50 J/GH, 5000 W, 10.0 TH/s machine in operation since 3 March 2014) in income-bitfury55.csv. As of 15 May 2017 it continues to be profitable, and has operated for 1170 days. So far it has spent 9% of its total mining revenues to recoup electricity.

Bitfury 28nm (comes in different configurations, model assumes a 0.20 J/GH, 2000 W, 10.0 TH/s machine in operation since 28 February 2015) in income-bitfury28.csv. As of 15 May 2017 it continues to be profitable, and has operated for 808 days. So far it has spent 16% of its total mining revenues to recoup electricity.

Bitfury BF8162C16 (comes in different configurations, model assumes a 0.13 J/GH, 1300 W, 10.0 TH/s machine in operation since 12 October 2016) in income-bitfury16.csv. As of 15 May 2017 it continues to be profitable, and has operated for 216 days. So far it has spent 24% of its total mining revenues to recoup electricity.

KnCMiner Solar (comes in different configurations, model assumes a 0.07 J/GH, 700 W, 10.0 TH/s machine in operation since 4 June 2015) in income-solar.csv. As of 15 May 2017 it continues to be profitable, and has operated for 712 days. So far it has spent 6% of its total mining revenues to recoup electricity.

Profitability threshold assumption

The model presented in this post makes one assumption: it looks at the difference in hash rate between the beginning and end of a phase, and assumes it indicates how many machines were manufactured during that phase.

Hypothetically, if a machine is first put online, and if it is immediately decommissioned within the same phase (eg. mining is suddenly no longer profitable,) and if it is put online again in a subsequent phase (eg. mining is profitable again,) then the model would classify the extra hash rate as belonging to the wrong phase.

However this hypothetical scenario is implausible given the model’s parameter of $0.05/kWh, as shown by the chart below. The efficiency of the best and worst hardware manufactured over time (“best J/GH” and “worst J/GH” data from the first chart) is compared to the profitability threshold2 below which a machine mines profitably:

Efficiency of machines compared to profitability threshold

The worst line never intersects the threshold. The least efficient machines remain profitable during their entire phase of production. So the model’s assumption is valid.

Summary

We can calculate the upper bound for the global electricity consumption of Bitcoin miners by assuming they deploy the least efficient hardware of their time and never upgrade it. As to the lower bound it can be calculated by assuming everyone has upgraded to the most efficient hardware. The table below summarizes the model’s estimates as of 26 February 2017:

  Lower bound Best guess Upper bound
Power consumption (MW) 325 470-540 774
Energy consumption (TWh/yr) 2.85 4.12-4.73 6.78
Energy consumption (Mtoe/yr) 0.245 0.354-0.407 0.583
Energy consumption (quad Btu/yr) 0.010 0.014-0.016 0.023
Percentage of world’s energy consumption5 0.00260% 0.00376-0.00432% 0.00619%
Electricity cost (million USD/yr)6 $142 $206-$237 $339
Energy efficiency (J/GH) 0.100 0.145-0.165 0.238

I kept the above table for reference as of the time this post was written, and have also produced new estimates as of 28 July 2017 (10-day avg hash rate of 6398 PH/s):

  Lower bound Best guess Upper bound
Power consumption (MW) 640 816-944 1248
Energy consumption (TWh/yr) 5.61 7.15-8.27 10.93
Energy consumption (Mtoe/yr) 0.482 0.615-0.711 0.940
Energy consumption (quad Btu/yr) 0.019 0.024-0.028 0.037
Percentage of world’s energy consumption5 0.00512% 0.00652-0.00755% 0.00998%
Electricity cost (million USD/yr)6 $280 $357-$413 $547
Energy efficiency (J/GH) 0.100 0.128-0.148 0.195

This may sound like a lot of electricity but when considering the big picture I believe Bitcoin mining is not wasteful. Also an interesting comparison to make is that according to a 2008 study from the United States Energy Department’s Energy Information Administration (EIA) these figures are comparable to or less than the annual electricity consumption of decorative Christmas lights in the country (6.63 TWh/year.)

Lastly, when modeling the costs and revenues of a miner over its entire life such as the Antminer S5, we find out that the hardware cost is as high as, if not higher than its lifetime electricity cost. Therefore a miner’s business plan should not look at the electricity costs alone, and cannot trivialize hardware costs when calculating expected profitability.

Updates

On 11 March 2017 I removed the assumption that sales of A3218 dwindled down to practically zero post-June 2016, because although sales volume did decrease I do not have precise metrics to justify it.7

On 13 March 2017 I made the calculation of the upper bound for the electricity consumption more accurate (was 861 MW, now 774 MW), thanks to A3218 production volume provided by Canaan.

On 16 March 2017 I added the section Economics of mining.

On 30 March 2017 I added the comparison to the electricity consumption of decorative Christmas lights.

On 16 May 2017 I reworked the section Economics of mining to add more miners such as S7, S9.

On 4 June 2017 I added all miners released in the last 2.5 years to the section Economics of mining.

On 28 July 2017 I produced updated estimates in the conclusion.

On 28 August 2017 I added the section Profitability threshold assumption.

References and commentary

The chart covers the period 15 December 2014 to 26 February 2017. Starting as early as December 2014 is sufficient for accurate modeling because only one ASIC released in phase 0 is still profitable: Bitfury BF864C55. All others are no longer profitable.

The daily hash rate data was obtained from Quandl; the curve was smoothed out by calculating each day as the average of this day and the 9 previous ones.

The cost of electricity is assumed to be $0.05/kWh which is half the worldwide average. It is logical to assume miners seek geographical locations with the cheapest electricity.

All energy efficiency values given in joule per gigahash are reported at the wall, taking into account the power supply’s efficiency.

Mining hardware manufacturers only sell one generation of miners at any given time. Usually it is a result of producing and selling small batches one by one, as Bitmain and Canaan have done. But it is also a result of aggressive competition: when a company launches a new ASIC significantly outperforming the efficiency of the competition, their sales come to a stop until a more efficient successor is available, as Canaan CEO N.G. Zhang recounted. Therefore my model actually errs toward overestimating electricity consumption by assuming that the previous ASIC generation is being sold/deployed at the same rate until the very day preceding the introduction of the next generation, which we know is not true in some cases.7

KnCMiner:

  • Neptune launched in June 2014 and achieves 0.70 J/GH.
  • Solar launched in June 2015 and achieves 0.07 J/GH. The company declared bankruptcy in May 2016, however they certainly stopped deploying mining capacity months earlier. This chart assumes they stopped in January 2016. Later, KnCMiner was bought by GoGreenLight. So far they have not added new hash power, but merely reactivated the hardware they acquired.

Spondoolies:

  • RockerBox was included in the SP20/SP30/SP31/SP35 Yukon product series; it launched in May 2014 and achieves 0.66 J/GH. The company failed to launch its successors—PickAxe, RockerBox II—and declared bankruptcy in May 2016, however they certainly stopped selling products months earlier as they were far behind competition in terms of energy efficiency. This chart assumes sales stopped in January 2016.8

Bitfury:

  • BF864C55 launched in March 2014 and achieves 0.50 J/GH.
  • Their 40nm ASIC never entered full-scale production, hence its absence from the chart.
  • Their 28nm ASIC launched in February 2015 and achieves 0.20 J/GH.
  • BF8162C16 launched in October 20169 and achieves 0.06 to 0.13 J/GH. This wide efficiency range is due to the ASIC being operated in a variety of configurations—sometimes manufactured by third parties—from air cooling (1, 2) to immersion cooling (1, 2, 3) where voltages and clocks are pushed to their limits.

Bitmain:

Canaan:

Footnotes

  1. In an email exchange with Canaan staff (VP of Engineering Xiangfu Liu, Jon Phillips, and Wolfgang Spraul) they gave me the following historic metrics:

    • A3222:
      • number of wafers made: ca. 950
      • number of chips per wafer: ca. 3330
      • performance per chip: 25 GH/s
      • total: 79 PH/s
    • A3218:
      • number of wafers made: ca. 1100
      • number of chips per wafer: ca. 3650
      • performance per chip: 47.5 GH/s
      • total: 191 PH/s

    2

  2. The profitability threshold in joule per gigahash is calculated as such:
    1e9 (1 GH/s) / (2^32 × difficulty) × block_reward × usd_per_btc / usd_per_kwh × 3.6e6 (joules per kWh)
    As of 26 February 2017 (difficulty = 441e9, 1 BTC = 1180 USD, $0.05/kWh) the profitability threshold is 0.56 J/GH:
    1e9 / (2^32 × 441e9) × 12.5 × 1180 / 0.05 × 3.6e6 = 0.56 J/GH
    So 3 ASICs in the chart are no longer profitable: Neptune, RockerBox, and A3222. 2

  3. Most of the hardware deployed during phase 0—CPUs, GPUs, FPGAs, first-generation ASICs—has not been profitable for a long time, so we make the assumption these miners upgraded to the least efficient ASIC available at the end of phase 0 that is still profitable: BM1384.

  4. However another investor who on 27 December 2014 bought $418 worth of bitcoins would be worth $818 on 8 October 2016, a 2.0× gain. It could be argued that a large reason why mining was profitable came simply from BTC gaining value.

  5. The world’s consumption of energy for year 2014 was 9 425 Mtoe, or 109 613 TWh, or 12.51 TW, according to IEA statistics. 2

  6. Electricity cost assumes $0.05/kWh. 2

  7. In an email thread with Canaan staff, although they were unable to give metrics, they confirmed that sales of the A3218 slowed down after June 2016 when competitor Bitmain launched BM1387 with a 3× better efficiency. 2

  8. I reached out to Spondoolies CEO Guy Corem to get official confirmation of when their sales stopped, but have not received a reply so far.

  9. In a 2015 post on HackerNews I previously incorrectly assumed hardware based on this ASIC launched in December 2015 but large-scale deployment only started in October 2016, as shown by this tweet from Bitfury Executive Vice Chairman George Kikvadze.

Comments

oregonmines wrote: Nice chart , the 100% by least efficient method, is an interesting way to look at a chips contribution hash wise. 11 Mar 2017 18:10 UTC

hashingitcom wrote: I like it - I've not run the estimates on mining for a while (busy with other stuff), but I just found one from about 2 years ago where I'd estimated a best case of 160 MW, and a more likely 320 MW at that point in time.

Do your energy figures allow for just the ASIC characteristic or have you factored other inefficiencies (especially in PSUs, cooling, etc.)?
30 Mar 2017 09:46 UTC

mrb wrote: Yes my estimates do take into account inefficiencies (1) of power supplies and (2) of the cooling at the chassis level, because J/GH figures are measured "at the wall."

There is also the PUE to consider (overhead at the data center level) which is typically very low for mining farms, 1.05 or so. But the *lower and upper bounds* do not need to take into account the PUE. The lower bound, by nature, needs to assume the overhead is zero. And the upper bound is such a worst-case & unrealistic estimate (by assuming miners deploy the least efficient hardware) that it must surely already overestimate power by at least 5%.

For my *best guess* estimates, in theory I should add 5%. But the variance is pretty large at 470-540 MW and not meant to be 5% accurate, so it would not be useful to do so.
30 Mar 2017 21:13 UTC

CW wrote: Thanks for sharing your analysis. It helped me clear a lot of misunderstandings I had.

I still don't understand how to calculate the lifetime income of a miner "By 15 January 2016 84% of the lifetime income of the S5 had been generated". I reviewed the income-antminer-s5.csv but still I cannot understand how you make this calculation. Thanks.
21 Apr 2017 00:43 UTC

mrb wrote: CW: By 15 Jan 2016 it had generated $854 of income (last column) which is 84% of the lifetime income of $1021. Well, to be pedantic the lifetime income moved a little bit upward and downward past Jan 2016, depending on diff and BTC price, and stabilized at $1030... 23 Apr 2017 04:10 UTC

janhoy wrote: This article http://digiconomist.net/bitcoin-energy-consumption claims an electricity consumption of 110KWh per transaction. What is your take on that? 09 May 2017 13:16 UTC

janhoy wrote: Ok, I just found your other article at http://blog.zorinaq.com/bitcoin-mining-is-not-wasteful/ which I believe explains it :) 09 May 2017 13:43 UTC

mrb wrote: Yes. Although my full response to and criticism against Digiconomist is at http://blog.zorinaq.com/serious-faults-in-beci/ 10 May 2017 22:18 UTC

SRSroccoReport wrote: Marc... excellent work on Bitcoin energy consumption. I run the SRSroccoReport.com site and I analyze how energy & the falling EROI - Energy Returned on investment will impact precious metals, mining, paper assets and the overall economy.

I see you have had a debate with Digiconomist on the energy consumption and cost to produce bitcoin.

I am trying to find out a basic cost of production for bitcoin and ethereum, as I believe this would at least provide a floor for their price.

Can you reply here or contact me at SRSroccoReport@gmail.com. I would enjoy hearing what you would gauge as a current total cost to produce bitcoin and ethereum. I do realize their costs will continue to increase as time goes by, but it would be helpful in comparing cost of production to their market price... especially now that they are highly inflated above their cost of production.

best regards,

steve
29 May 2017 05:02 UTC

mrb wrote: steve: Per the math in footnote 2, currently (difficulty = 596e9, 1 BTC = 2300 USD, assuming $0.05/kWh) the efficiency under which an ASIC is no longer profitable is 0.81 J/GH. An Antminer S9 operates at 0.10 J/GH, so electricity costs represent 12% of mining revenues (0.10/0.81), therefore 1 BTC costs 280 USD in electricity.

This doesn't count the cost of the hardware which has to be amortized over the lifetime of a miner. My models show that for an end-of-life miner like the S5, 28% of mining revenues need to cover hardware costs, so 1 BTC need to recover 640 USD of hardware costs.

So the overall production cost of 1 BTC is 920 USD. But even this number doesn't account for other smaller expenses: data center, labor. Call it ~10%. This places the overall production cost of 1 BTC at around 1010 USD.
31 May 2017 20:42 UTC

Robert L wrote: Thank you for sharing! Really enjoyed reading your analysis. It would be interesting to consider the true energy cost by considering the additional upper bounds of ~30% inefficiency in energy production and transportation to user. I would imagine the global mean is even higher.
https://www.eia.gov/totalenergy/data/annual/pdf/sec17.pdf

Thanks,
Robert.
12 Jun 2017 02:14 UTC

Digiconomist wrote: The problem of estimating Bitcoin energy consumption is a lack of a central register with all active machines. The only certain number is the absolute minimum energy consumption (hash * most efficient miner), but that number doesn't get close to reality as newer machines only slowly push the old ones out.

If you're going to derive energy consumption from actual hash you're going to have a pretty big error on the tail. This is the part with most older machines, that relatively have the most impact on total energy use (eg. just 50 PH/s of old S2 miners has the same weight as 500 PH/s of S9 miners).

The author heavily relies on economic assumptions in determining the activity of these older machines, which adds a lot of uncertainty regarding this so-called "bound". IMO this hasn't been properly disclaimed in the article. Still I'm happy with it, since it also validates the need for an economic indicator given the reliance on profitability assumptions.
15 Jun 2017 17:24 UTC

mrb wrote: Digiconomist: my upper bound already estimates the amount of such older machines by calculating the profitability breakeven point (0.56 J/GH), as explained and disclosed. 15 Jun 2017 19:44 UTC

Digiconomist wrote: Yes, but it doesn't disclose uncertainty surrounding that number. Average cost per KWh are an estimate, not a given. With 2 cents per KWh that break-even point would more than double & have a big impact on the tail. Only the lower bound is an actual bound. 16 Jun 2017 07:51 UTC

Digiconomist wrote: The way it's presented makes it seem like the upper bound is of equal strenght as the lower bound. While the lower bound only has some performance uncertainty surrounding it, but the upper bound is a diffent story. If the network was running even just slightly lower at 4 cents per KWh you'd have to include the A3222, which immediately adds 10%(+) to your bound (0.81 TWh). It's not that solid. 16 Jun 2017 08:07 UTC

Digiconomist wrote: On top of the previous the number is also sensitive to timing (after all there's no guarantee to when machines are actually deployed - shipping and setting up take time too) and hashrate measurement errors. Timing alone can easily add 5% to the bound (just try shifting the months up by one). And worse: these errors can also stack up. No taking the correct machines into account and getting the timing wrong will quickly result in a 20-30% error on the upper bound. 16 Jun 2017 19:20 UTC

mrb wrote: Yes the upper bound is influenced by the assumed cost of electricity, and there is some uncertainty about the cost. I disclose this assumption in multiple places.

But I do not believe a lower cost would have a significant impact on the tail. Machines produced pre-Dec 2014 (where my chart starts) were produced in relatively small quantities that even their aggregate power consumption is not that high.

Case in point: you are wrong about the A3222 potentially raising the upper bound by 10%, because only 79 PH/s of it were produced (see footnote.) If you do the math and assume 79 PH/s of it, then the upper bound only raises by 1.6%.

What about RockerBox and Neptune? Well again none of them were produced in large quantities: 0.3% of the hashrate is KnCMiner hardware, and Spodoolies bankrupted themselves due to low volume.

As to the timing of ASIC releases and hashrate measurements, the small inaccuracies should average out to zero (some data points slightly overestimating, others slightly underestimating.)

Finally, I want to reiterate that the upper bound is based on such an extreme assumption (everyone deploying the LEAST EFFICIENT machines) that it gives us an error margin large enough to account for the bound being potentially 5 or 10% off.

In the end, the real power consumption is going to be in between the lower and upper bound, far from each bound.
20 Jun 2017 04:56 UTC

Digiconomist wrote: Okay, so I quickly calculated the weight each phase has and put the result in the chart here:

http://imgur.com/sYZEBYa

As you can see early phases are responsible for just 14% of the hash, but 29% of the calculated energy consumption is due to these machines. Late stage miners obviously carry a lot more hash (38%), but have a lot less impact on the final figure (they contribute 24%).

I also created one showing what happens when you change phase 0 only. Here's the result of putting it closer to 1 J/GH:

http://imgur.com/a/UMBSN

Doing so would cause early phases to be responsible for 40% of the total energy consumption figure, and raise the overall number by 15%. This is what an error in just 290 PH/s at the start can do to your figure. Small number, massive energy weight.

Today the break-even J/GH for the network is 0.92 at 5 cents per KWh. We know rates can go as low as 2 cents. Where does that leave old Bitmain S2, S3 and S4 miners? They run at <= 1 J/GH. I'd say this really adds quite some uncertainty to the proposed method.

One more thing. I was wondering why the method wasn't repeated in reverse? If you can do it for the least efficient machines why not with the most efficient ones? This would make for a more interesting "lower bound". At least more comparable to the upper one.
20 Jun 2017 20:59 UTC

mrb wrote: If you are going to input bad numbers into my model, you are going to get bad results out :)

You cannot put phase 0 at 1 J/GH. As my chart shows, it is impossible to have 290 PH/s of ASICs averaging 1 J/GH. Why? Because as of Dec 2014 all ASICs being sold (Neptune, RockerBox, BF864C55, BM1384, A3222) were in the range 0.50-0.70 J/GH and the network was measuring 290 PH/s. That means a unknown but significant fraction of the hashrate was already 0.50-0.70 J/GH. Therefore the average of a distribution of machines between 0.50 (best) and 1 J/GH (break-even) is going to be a number below 1 J/GH.

In other words you would need a break-even point significantly above 1 J/GH (maybe 2 J/GH or so) for the average of phase 0 to be 1 J/GH.

Furthermore, you are wrong about 0.92 J/GH. As of 20 Jun 2017 (when you wrote your post) the break-even at $0.05/kWh was 0.79 J/GH (1 BTC = 2700 USD, diff = 712e9).

And as of 10 Jul 2017 (1 BTC = 2350 USD, diff = 709e9) the break-even is even lower at 0.69 J/GH.

If we bumped phase 0 from 0.51 to 0.69 J/GH it would increase my worst case power consumption from 774 to 826 MW, a 7% increase. And just as I said in my previous message, being 5 or 10% off is already accounted for.
11 Jul 2017 01:42 UTC

Digiconomist wrote: I put in 1 J/GH to show how sensitive your model is to estimation errors in the small tail (in terms of hashrate). Market leader Bitmain was only putting out less efficient machines at this point, but they haven't really been considered for this article even though there's a potential big impact in there. The new machines are never the problem when estimating energy consumption, it's the older ones that present the biggest challenge and are responsible for the majority consumption (e.g. phase 9 accounts for ~40% of the hash but only ~20% of the energy consumption).

A second problem I see in the model is the lack of consistency. Economics are used to cut the tail, but if applied consistently I would expect some spillover effects (so the hashrate increase during a period can never be completely attributed to the machines available during that period). This is as simple as: price goes down at time t, I turn off my machines, price increases fourfold at time t + 1, I turn my machine on again. This is something to be analyzed throughout, as it could cause a bias towards new more efficient machines.

I think you're missing fees in the BE point calculation by the way. There can be a small difference based on what difficulty adjustment is applied, but the gap is too big so fees must be left out (around 18% of the total reward on Jun 20). I'm a lot closer for Jul 10 (0.77 J/GH), but fees have more than halved at this point.
14 Jul 2017 11:56 UTC

mrb wrote: As per my previous msg, I calculated that if we significantly bumped phase 0 by 35% (0.51 to 0.69 J/GH) it would increase the worst case power consumption by 7%. So, no, a 35% input variation causing a 7% output variation doesn't show a particularly high sensitivity in the tail estimation.

The last machine Bitmain was shipping before Dec 2014 (AntMiner S4) was 0.69 J/GH. Therefore the snapshot presented in this research as of 26 Feb 2017 (break-even of 0.56 J/GH) was correct to ignore the S4 as it has worse efficiency. There is no potential big impact that the model is missing.

As to miners shutting down at t and resuming at t+1, yes it may have a small effect on the worst case numbers. If I have time I will correlate the evolution of the break-even with phases and see where its impact might be the greatest. But I don't expect the effect to be very large. After all, later phases saw the introduction of machines more powerful than earlier phases, so only a minority of the hashrate added at a given phase might come from older machines.

As to fees, I didn't take them into account because they don't need to. As of 26 Feb 2017 they represented 9% of the mining income (170 BTC daily as per https://blockchain.info/charts/transaction-fees?daysAverageString=7&timespan=1year), so the break-even including fees was 0.61 not 0.56. This doesn't change my phase 0 assumption: the least efficient yet profitable miner is still the BM1384.
16 Jul 2017 01:10 UTC

Digiconomist wrote: So we've exchanged some emails in which I explained why I think this method is based on cherry picking, and instead of providing any follow-up you decided to quote mine my emails to support false statements about my energy index.

Rather ironic don't you think? For anyone interested the email dump can be found here: https://digiconomist.net/re-serious-faults-in-beci
22 Aug 2017 07:42 UTC