From: Eric Voskuil <eric@voskuil•org>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Date: Thu, 03 Mar 2016 12:54:24 -0800 [thread overview]
Message-ID: <56D8A480.6040604@voskuil.org> (raw)
In-Reply-To: <20160302230213.GA888@muck>
[-- Attachment #1: Type: text/plain, Size: 4004 bytes --]
On 03/02/2016 03:02 PM, Peter Todd wrote:
> On Wed, Mar 02, 2016 at 11:01:36AM -0800, 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.
>
> You know, I do agree with you.
>
> But see, this is one of the reasons why we keep reminding people that
> strictly speaking a hardfork *is* an altcoin, and the altcoin can change
> any rule currently in Bitcoin.
>
> It'd be perfectly reasonable to create an altcoin with a 22-million-coin
> limit and an inflation schedule that had smooth, rather than abrupt,
> drops. It'd also be reasonable to make that altcoin start with the same
> UTXO set as Bitcoin as a means of initial coin distribution.
>
> If miners choose to start mining that altcoin en-mass on the halving,
> all the more power to them. It's our choice whether or not we buy those
> coins. We may choose not to, but if 95% of the hashing power decides to
> go mine something different we have to accept that under our current
> chosen rules confirmations might take a long time.
>
> Of course, personally I agree with Gregory Maxwell: this is all fairly
> unlikely to happen, so the discussion is academic. But we'll see.
>
I agree, this is a perfectly rational interpretation. I also agree that
this particular instance is academic. But I see more to this than
accepting what is possible.
In the case of Federal Reserve Notes the gold obligation was abrogated.
This was (at least) a contract default, implemented by force of arms.
This contentious hard fork was clearly an attack.
But in a system with no authority and in which nobody has formed a
contractual obligation with anyone else, what would constitute an attack
on the money? There is no difference between state attacks on (or
collusion with) miners and miners acting on self interest.
One answer is that nothing is an attack, it's up to the market to
decide. But to the extent that there can be an attack on the money, the
attempt to move the value of the coin to an altcoin (hard fork) is it.
Though the choice of the term "attack" isn't essential.
The importance of recognizing an attack is that it affords one the
opportunity to defend against it. People holding "dollars" in 1933 were
ill equipped to defend against a system level attack (monetary policy),
in part because many did not recognize it as such, and in part because
there was insufficient preparation by those who did.
I see us building the tools and awareness necessary for defense. As you
say, nobody has to buy into an altcoin forked from their coin. This much
is simple to achieve. The more difficult problem is preserving the
utility of the original coin. Clearly the purpose of a hard fork (as
opposed to a new coin) is to transfer this value.
We've all seen arguments for contentious hard fork deployment that
explicitly depend on the fear of monetary loss to drag people to
acceptance. While this may be the nature of the technology, it's
important that we develop effective defense against it.
Ultimately the only defense is individual validation. The collusion of
banks (web wallets) with miners in attacking consensus is obvious. But
even without active collusion, the surrender of validation leaves people
just as defenseless as *being* unarmed while retaining a right to
*become* armed.
Even if every person mines at the same level, the system amounts to
little more than majority rule if validation is not decentralized. There
are people perfectly willing to exploit this weakness.
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-03-03 20:54 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
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 [this message]
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=56D8A480.6040604@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/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