public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Henning Kopp <henning.kopp@uni-ulm.de>
To: Corey Haddad <corey3@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Date: Fri, 4 Mar 2016 09:41:02 +0100	[thread overview]
Message-ID: <20160304084101.GA2352@banane.informatik.uni-ulm.de> (raw)
In-Reply-To: <CAK_HAC9v8ZuOKBQQZ4TJa2vdmEuOM-ykqEAMvaLgUn-Cr13Yww@mail.gmail.com>

Hi,

> However, I think it could actually increase
> confidence in the system if the community is able to demonstrate a good
> process for making such decisions, and show that we can separate the
> meaningful underlying principles, such as the coin limit and overall
> inflation rate, from what is more akin to an implementation detail, as I
> consider the large-step reward reduction to be.

I do not think that a line can be drawn here. As far as I understood,
you think that the coin limit is a meaningful underlying principle
which should not be touched, whereas the halving of mining rewards is
an implementation detail. The two are very closely tied together and
changes to both of them would result in a hardfork, if I am not
mistaken.

Regarding the effects of the mining reward halving, there is a nice
paper from courtois:
http://arxiv.org/abs/1405.0534

All the best
Henning



On Thu, Mar 03, 2016 at 10:27:35AM -0800, Corey Haddad via bitcoin-dev wrote:
> Since the root cause of what you are trying to address is the reward
> having, I'd suggest considering an adjustment to the having schedule.
> Instead of their being a large supply shock every four years, perhaps the
> reward could drop every 52,500 blocks (yearly), or even at each difficulty
> adjustment, in such a way that the inflation curve is smoothed out.  The
> exponential decay rate would be preserved, so overall economic philosophy
> would be preserved.
> 
> I'm guessing hesitance to this approach would lie in a reluctance to tinker
> with Bitcoin's 'economic contract', and slippery slope concerns about might
> be the next change (21M?).  However, I think it could actually increase
> confidence in the system if the community is able to demonstrate a good
> process for making such decisions, and show that we can separate the
> meaningful underlying principles, such as the coin limit and overall
> inflation rate, from what is more akin to an implementation detail, as I
> consider the large-step reward reduction to be.
> 
> I'm not too worried about the impact of the having as is, but adjusting the
> economic parameter would be a safer and simpler way to address the concerns
> than to tinker with the difficulty targeting mechanism, which is at the
> heart of Bitcoin's security
> 
> On Wed, Mar 2, 2016 at 6:56 AM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > We are coming up on the subsidy halving this July, and there have been some
> > concerns raised that a non-trivial number of miners could potentially drop
> > off
> > the network. This would result in a significantly longer block interval,
> > which
> > also means a higher per-block transaction volume, which could cause the
> > block
> > size limit to legitimately be hit much sooner than expected. Furthermore,
> > due
> > to difficulty adjustment being measured exclusively in blocks, the time
> > until
> > it adjusts to compensate would be prolonged.
> >
> > For example, if 50% of miners dropped off the network, blocks would be
> > every
> > 20 minutes on average and contain double the transactions they presently
> > do.
> > Even double would be approximately 850-900k, which potentially bumps up
> > against the hard limit when empty blocks are taken into consideration. This
> > situation would continue for a full month if no changes are made. If more
> > miners drop off the network, most of this becomes linearly worse, but due
> > to
> > hitting the block size limit, the backlog would grow indefinitely until the
> > adjustment occurs.
> >
> > To alleviate this risk, it seems reasonable to propose a hardfork to the
> > difficulty adjustment algorithm so it can adapt quicker to such a
> > significant
> > drop in mining rate. BtcDrak tells me he has well-tested code for this in
> > his
> > altcoin, which has seen some roller-coaster hashrates, 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. If this slips, I
> > think it may be reasonable to push for at least code-readiness before July,
> > and possibly roll it into any other hardfork proposed before or around that
> > time.
> >
> > I am unaware of any reason this would be controversial, so if anyone has a
> > problem with such a change, please speak up sooner rather than later. Other
> > ideas or concerns are of course welcome as well.
> >
> > Thanks,
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


-- 
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany

Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp


  reply	other threads:[~2016-03-04  8:41 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
     [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 [this message]
     [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=20160304084101.GA2352@banane.informatik.uni-ulm.de \
    --to=henning.kopp@uni-ulm.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=corey3@gmail.com \
    /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