From: Eric Voskuil <eric@voskuil•org>
To: Paul Sztorc <truthcoin@gmail•com>, bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Date: Wed, 02 Mar 2016 12:44:07 -0800 [thread overview]
Message-ID: <56D75097.2070609@voskuil.org> (raw)
In-Reply-To: <56D74859.3090609@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3813 bytes --]
On 03/02/2016 12:08 PM, Paul Sztorc wrote:
> On 3/2/2016 2:01 PM, Eric Voskuil via bitcoin-dev wrote:
>>> 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.
>
> The Ministry of Truth is taking job applications in the doublespeak
> department...
Not sure how you interpret a tautology as doublespeak.
>> 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.
>
> Coinbase-smoothing can be done via soft fork (soft forks typically only
> move "one way" toward stability).
I'm addressing the hard fork proposal (see subject line).
> Moreover, the effect *costs* miners,
> it does not benefit them. Finally, it can be done so that the economic
> impact on miners is minimized.
Changes to consensus rules change the value of coins, which are property
of their owners. Nobody owes a miner a promise of consistent revenue for
future work. Cost or benefit to miners is relevant only to the extent
that those who hold money believe it will affect their value and
therefore consider it in their decision to consent.
> You'll just have to weigh the risks -- some vague, tiny effect on
> expectations today, vs the need for a small group of experts to
> emergency hard fork once every four years.
How is the small group of experts today different from the small group
of experts tomorrow?
> I'm sure those experts are completely reliable, and won't get threatened
> or assassinated!
This is precisely the issue. The precedent of hard-forking to "fix" the
money is a precedent for establishing authority over the money.
>> 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.
>
> The word "loss" is of utmost importance here...if they are operational
> losses, it should be obvious to everyone that the best "compensation for
> losses in the 2nd period" is to just shut them off (thus reducing losses
> to zero).
But of course the losses would not be entirely operational, since
hardware (at a minimum) does not depreciate to zero because of a
halving. The ability to plan does not change this fact. There are
certainly similar considerations for labor, bandwidth, space and even
electrical/cooling costs (contracts). To the extent that these costs are
sunk (as Tier said) *any* earnings are better than none.
> So you must be arguing that miners have made an investment 3 months
> prior, knowing that it would pay for itself despite the reward halving.
Of course, how could they not?
> That's nice, but it ignores the fact that, if that investment is made
> everyone, by all miners, the *difficulty* will have increased 2 weeks
> afterward...such that operating profits are tending *immediately* toward
> zero, and will be zero by the time the first set of 3 months is over.
... which also ignores fees.
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-03-02 20:44 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 14:56 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
[not found] ` <56D74859.3090609@gmail.com>
2016-03-02 20:44 ` Eric Voskuil [this message]
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=56D75097.2070609@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=truthcoin@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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