public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Paul Sztorc <truthcoin@gmail.com>
To: Luke Dashjr <luke@dashjr.org>, bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Date: Wed, 2 Mar 2016 11:27:52 -0500	[thread overview]
Message-ID: <56D71488.4080607@gmail.com> (raw)
In-Reply-To: <201603021542.29609.luke@dashjr.org>

It is **essential** that emergency code be prepared. This code must be
able to lower the difficulty by a large factor.

---

This halving-difficulty-drop problem can, with some bad luck, get quite
disastrous, very quickly.

( I did a micro-study of this problem here, for those who are unaware:
http://www.truthcoin.info/blog/mining-heart-attack )

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. If miners are all equal, difficulty causes
their profit margin to narrow over time (for example, if BTC revenues
are $100, and amortized fixed costs are $10, then difficulty adjustments
will cause total energy costs to rise to ~ $89, such that total
pre-halving profit is $1 for everyone...post-halving, profit is -$49 for
everyone).

So, if miners are homogenous the result is disastrous. Fortunately,
miners are probably still somewhat heterogenous. However, we don't know
how their power contracts (or their hardware turnover) are
scheduled...many miners might (?) have already planned, in private, to
close down (or substantially reduce) operations after the halving.

As the coinbase rewards are currently orders of magnitude larger than
tx-fees, fees are unlikely to be able to compensate for this. Users may
decide to simply hold-off on transacting until fees decrease.

Worse, if the price crashes (possibly as a result of uncertainty
surrounding this episode), it will begin to affect miner-revenue.

As a result, miners may decide to temporarily halt mining until the
difficulty falls naturally.

But such a temporary halt is also (potentially) disastrous. Recall the
simple fact that difficulty adjustments are measured in blocks, not time
(it appears that we have exactly 1015 blocks between the halving block
and the next difficulty adjustment block). If excessive difficulty
chokes the system, next difficulty adjustment may *never* arrive naturally.

In this worst-case (but somewhat plausible) scenario, we will be
*forced* to lower the difficulty via hard fork, and we will be forced to
do so very very QUICKLY, as word will be spreading that the Bitcoin
system has broken!

If a specific hard fork is not coded and tested for this, in advance,
the delay might be accompanied by endless [contentious] conversations
about what else should be included in this hard fork.

Worse, since all users will need to upgrade, there will be uncertainty
over contentious versions, malicious agents may try to tamper with
versions (to steal Bitcoins), etc. We should consider pushing a version
out for users to upgrade, in advance of the halving, as soon as possible.



What a disaster! I certainly hope it does not happen, but if it does we
should have already agreed on what to do.


One choice is "which number do we set the difficulty to?". Half may be
too much, or too little. However, allow me to suggest that, if this
disastrous scenario occurs, we shouldn't take any chances, and reduce
difficulty by a huge proportion...80% or so. The difficulty will then
quickly begin to increase again...we can warn users of the increased
orphan risk, and that they should wait for many confirmations (which
should be happening faster).

So, "Allow the alert key to reduce the difficulty by 80%, exactly once
on one of the 1015 blocks between halving and difficulty adjustment."

And we should consider smoothing the rewards (as described in my post,
can be done via soft fork) to prevent this from happening again. In
microeconomics literature, 'kinks' in incentive-systems are
almost-universally agreed to be very undesirable.

Paul


On 3/2/2016 10:42 AM, Luke Dashjr via bitcoin-dev wrote:
> On Wednesday, March 02, 2016 2:56:14 PM Luke Dashjr via bitcoin-dev wrote:
>> so it may even be possible to have such a proposal ready in time to be
>> deployed alongside SegWit  to take effect in time for the upcoming subsidy
>> halving.
> 
> Lapse of thinking/clarity here. This probably isn't a practical timeframe for 
> deployment, unless/until there's an emergency situation. So if the code were 
> bundled with SegWit, it would need some way to avoid its early activation 
> outside of such an emergency (which could possibly be detected in code, in 
> this case).
> 
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 


  reply	other threads:[~2016-03-02 16:27 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 [this message]
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
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=56D71488.4080607@gmail.com \
    --to=truthcoin@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.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