public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Alex Waters <ampedal@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues
Date: Wed, 14 Sep 2011 17:51:30 -0400	[thread overview]
Message-ID: <CAAS2fgQJqRZ0wPak3Ub1nN6gp9Y1MgU=rgPGTZMwPZZ7Mc5JYg@mail.gmail.com> (raw)
In-Reply-To: <CAL0fb62X5-yZQbVMd6zeS590jbaa1nKRH-wYWkKXRHxCtuy=kQ@mail.gmail.com>

On Wed, Sep 14, 2011 at 5:36 PM, Alex Waters <ampedal@gmail.com> wrote:
> On Wed, Sep 14, 2011 at 4:28 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
>
>> What do other people think?  I think it is too high risk for too
>> little benefit and shouldn't be done until we have a really compelling
>> reason to introduce a forking change.
>
> Could we bundle this and potential future blockchain-splitting changes
> - to implement them in a major release (down the road)? Or save them
> for when they are very necessary?
>
> TL;DR shelf it until needed, have it written just in case.

I'm generally opposed to doing "too much" at once in this kind of change.

Some changes, like this one, are completely uncontroversial (except
some argument about having fork causing change at all) where some have
more complicated social/economic impacts (the block size being among
them, though probably not the worst).

Moreover, the longer we go between such changes the more the cost is
perceived to be infinite. Better to take one per year, with six months
of gap between implementation, and give everyone the right
expectations than to have prolonged arguments due to our inexperience
that only get trumped by emergency changes.

General network health and user security _requires_ periodic upgrades
in any case, and will for the foreseeable future. The whole notion
that old versions will _stop working_ would be a pretty good thing at
this point in bitcoin's existence, judging by the high number of
pre-.24 listeners still reported.



  reply	other threads:[~2011-09-14 21:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-13 15:06 [Bitcoin-development] Difficulty adjustment / time issues Gavin Andresen
2011-09-13 15:15 ` Vladimir Marchenko
2011-09-13 15:54 ` John Smith
2011-09-13 16:24 ` kjj
2011-09-14 14:45   ` Gavin Andresen
2011-09-14 15:43     ` Luke-Jr
2011-09-14 16:06       ` Christian Decker
2011-09-14 19:52     ` Aidan Thornton
2011-09-14 20:09       ` Gregory Maxwell
2011-09-14 20:28         ` Gavin Andresen
2011-09-14 21:36           ` Alex Waters
2011-09-14 21:51             ` Gregory Maxwell [this message]
2011-09-14 22:07               ` theymos
2011-09-14 23:01         ` Luke-Jr
2011-09-13 16:48 ` Luke-Jr
2011-09-14 21:45 ` theymos
2011-11-07 15:02 ` Pieter Wuille
2011-11-07 15:27   ` Luke-Jr
2011-11-07 15:43     ` Pieter Wuille

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='CAAS2fgQJqRZ0wPak3Ub1nN6gp9Y1MgU=rgPGTZMwPZZ7Mc5JYg@mail.gmail.com' \
    --to=gmaxwell@gmail.com \
    --cc=ampedal@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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