public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jonathan Toomim <j@toom.im>
To: jl2012@xbt.hk
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
Date: Sun, 7 Feb 2016 09:56:48 -0800	[thread overview]
Message-ID: <7D9FA815-D816-4DFD-B96A-469C9051885F@toom.im> (raw)
In-Reply-To: <22e401d161cc$66af6b50$340e41f0$@xbt.hk>


[-- Attachment #1.1: Type: text/plain, Size: 2429 bytes --]

On Feb 7, 2016, at 9:24 AM, jl2012@xbt.hk wrote:

> You are making a very naïve assumption that miners are just looking for profit for the next second. Instead, they would try to optimize their short term and long term ROI. It is also well known that some miners would mine at a loss, even not for ideological reasons, if they believe that their action is beneficial to the network and will provide long term ROI. It happened after the last halving in 2012. Without any immediate price appreciation, the hashing rate decreased by only less than 10%
> 


In 2012, revenue dropped by about 50% instantaneously. That does not mean that profitability became negative.

The difficulty at the time of the halving was about 3M. The exchange rate was about $12. A common miner at the time was the Radeon 6970, which performed about 350 Mh/s on 200 W for about 1.75 Mh/J. A computer with 4 6970s would use about 1 kW of power, once AC/DC losses and CPU overhead are taken into account. This 1 kW rig would have earned about $0.22/kWh before the halving, and $0.11/kWh after the halving. Since it's not hard to find electricity cheaper than $0.11/kWh, the hashrate didn't drop much.

It's a common misconception that the mining hashrate increases until an equilibrium is reached, and nobody is making a profit any longer. However, this is not true. The hashrate stops increasing when the expected operating profit over a reasonable time frame is no longer greater than the hardware cost, not when the operating profit approaches zero. For example, an S7 right now costs a little over $1000. If I don't expect to earn more than $1000 in operating profit over the next year or two with an S7, then I won't buy one.

Right now, an S7 earns about $190/month and costs about $60/month to operate, for a profit of $120/month. After the halving, revenue would drop to $95/month (or less, depending on difficulty and exchange rate), leaving profit at about $35/month. The $120/month profit is good enough motivation to buy hardware now, and the $35/month would be good enough motivation to keep running hardware after the halving.

I know in advance when the halvings are coming. There's going to be one in about 5 months, for example. I'm going to stop buying miners before the halving even if they're very profitable for a month because I don't want to be stuck with hardware that won't reach 100% return on investment (ROI).



[-- Attachment #1.2: Type: text/html, Size: 3231 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

  reply	other threads:[~2016-02-07 17:54 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 20:51 [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes Gavin Andresen
2016-02-05 22:36 ` Yifu Guo
2016-02-07 17:09   ` Gavin Andresen
2016-02-05 23:04 ` Btc Drak
2016-02-06  0:12 ` Luke Dashjr
2016-02-06  3:14   ` Jorge Timón
2016-02-06 15:37     ` Gavin Andresen
2016-02-06 17:01       ` Adam Back
2016-02-06 17:45         ` Gavin Andresen
2016-02-06 21:11           ` Peter Todd
2016-02-06 21:24             ` Peter Todd
2016-02-09  5:11             ` Samson Mow
2016-02-06 21:28           ` David Thomson
2016-02-07 18:49         ` Chris Priest
2016-02-06 17:09       ` Jorge Timón
2016-02-06 17:25         ` Tom Zander
2016-02-06 20:22           ` Chris Priest
2016-02-06 20:46           ` Luke Dashjr
2016-02-07 14:16             ` Gavin Andresen
2016-02-07 15:06               ` Alex Morcos
2016-02-07 16:54                 ` Peter Todd
2016-02-07 15:19               ` Anthony Towns
2016-02-07 17:10                 ` Jonathan Toomim
2016-02-07 17:24                   ` jl2012
2016-02-07 17:56                     ` Jonathan Toomim [this message]
2016-02-07 21:01               ` Luke Dashjr
2016-02-07 21:33                 ` Steven Pine
2016-02-07 22:04                   ` Corey Haddad
2016-02-07 22:25                     ` Steven Pine
2016-02-06 20:36       ` Luke Dashjr
2016-02-06 22:22       ` Peter Todd
2016-02-07  5:21       ` Jannes Faber
2016-02-07 18:55         ` Jonathan Toomim
2016-02-07 19:03           ` Patrick Strateman
2016-02-07 19:19             ` Trevin Hofmann
2016-02-07 20:29             ` Tier Nolan
2016-02-09 13:59       ` Yifu Guo
2016-02-09 16:54         ` Gavin Andresen
2016-02-10  6:14           ` David Vorick
2016-02-10  6:36             ` Patrick Shirkey
2016-02-10 12:58             ` Tier Nolan
2016-02-07 11:37 ` Anthony Towns

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7D9FA815-D816-4DFD-B96A-469C9051885F@toom.im \
    --to=j@toom.im \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jl2012@xbt.hk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox