public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Eric Voskuil" <eric@voskuil.org>
To: <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Date: Wed, 2 Mar 2016 11:01:36 -0800	[thread overview]
Message-ID: <00e101d174b5$f2659060$d730b120$@voskuil.org> (raw)
In-Reply-To: <CAE-z3OWA0sn+=+qqs8BtiBe7T9Qdb4G8XAS_bX4hScq225iZQQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

> A 6 month investment with 3 months on the high subsidy and 3 months on low subsidy would not be made…

 

Yes, this is the essential point. All capital investments are made based on expectations of future returns. To the extent that futures are perfectly knowable, they can be perfectly factored in. This is why inflation in Bitcoin is not a tax, it’s a cost. These step functions are made continuous by their predictability, removing that predictability will make them -- unpredictable.

 

Changing these futures punishes those who have planned properly and favors those who have not. Sort of like a Bitcoin bail-in; are some miners are too big to fail? It also creates the expectation that it may happen again. This infects the money with the sort of uncertainty that Bitcoin is designed to prevent.

 

e

 

From: bitcoin-dev-bounces@lists.linuxfoundation.org [mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] On Behalf Of Tier Nolan via bitcoin-dev
Sent: Wednesday, March 2, 2016 10:08 AM
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

 

On Wed, Mar 2, 2016 at 4:27 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org> > wrote:

For example, it is theoretically possible that 100% of miners (not 50%
or 10%) will shut off their hardware. This is because it is revenue
which ~halves, not profit.

 

It depends on how much is sunk costs and how much is marginal costs too.

If hashing costs are 50% capital and 50% marginal, then the entire network will be able to absorb a 50% drop in subsidy.

50% capital costs means that the cost of the loan to buy the hardware represents half the cost.

Assume that for every $100 of income, you have to pay $49 for the loan and $49 for electricity giving 2% profit.  If the subsidy halves, then you only get $50 of income, so lose $48.  

But if the bank repossesses the operation, they might as well keep things running for the $1 in marginal profit (or sell on the hardware to someone who will keep using it).

Since this drop in revenue is well known in advance, businesses will spend less on capital.  That means that there should be less mining hardware than otherwise.

A 6 month investment with 3 months on the high subsidy and 3 months on low subsidy would not be made if it only generated a small profit for the first 3 and then massive losses for the 2nd period of 3 months.  For it to be made, there needs to be large profit during the first period to compensate for the losses in the 2nd period.


[-- Attachment #2: Type: text/html, Size: 6233 bytes --]

  reply	other threads:[~2016-03-02 19:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-02 14:56 [bitcoin-dev] Hardfork to fix difficulty drop algorithm Luke Dashjr
2016-03-02 15:05 ` Pavel Janík
2016-03-02 15:14   ` Luke Dashjr
2016-03-02 15:24     ` Jérémie Dubois-Lacoste
     [not found]     ` <CAE-z3OUR8So2EM_EBeEerW-UPs0KY+whVB=jjFAHkW3xZPF2Hw@mail.gmail.com>
2016-03-02 15:54       ` Tier Nolan
2016-03-02 15:42 ` Luke Dashjr
2016-03-02 16:27   ` Paul Sztorc
2016-03-02 18:07     ` Tier Nolan
2016-03-02 19:01       ` Eric Voskuil [this message]
     [not found]         ` <56D74859.3090609@gmail.com>
2016-03-02 20:44           ` Eric Voskuil
2016-03-02 23:02         ` Peter Todd
2016-03-03  5:11           ` Dave Scotese
2016-03-03 10:14           ` Patrick Shirkey
2016-03-03 20:54           ` Eric Voskuil
2016-03-04 10:27             ` Tier Nolan
2016-03-02 15:48 ` Dave Hudson
2016-03-08 22:05   ` Bob McElrath
2016-03-09 18:30     ` Dave Hudson
2016-03-09 20:21       ` Bob McElrath
2016-03-09 23:24         ` Dave Hudson
2016-03-09 20:26       ` Paul Sztorc
2016-03-02 16:17 ` Bryan Bishop
2016-03-02 17:14 ` David A. Harding
2016-03-02 17:53   ` Gregory Maxwell
2016-03-02 19:34     ` David A. Harding
2016-03-03  1:06     ` Paul Sztorc
2016-03-09 17:58       ` Paul Sztorc
2016-03-02 18:20 ` Peter Todd
2016-03-03 18:27 ` Corey Haddad
2016-03-04  8:41   ` Henning Kopp
     [not found]     ` <CA+XQW1gfnXxxCod6cL=caGnEc66YOvaF6SJL=omUbMqwLNDP7g@mail.gmail.com>
2016-03-09 20:43       ` Paul Sztorc

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='00e101d174b5$f2659060$d730b120$@voskuil.org' \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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