public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dave Scotese <dscotese@litmocracy.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] How much is too much time between difficulty changes?
Date: Mon, 3 Dec 2018 12:37:17 -0800	[thread overview]
Message-ID: <CAGLBAhdtXEjhZWavgytQAOuXUaJZc=ZQyvjB2KV-YczAh-H4WQ@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

The last difficulty change took about 20% longer than expected.  How large
does the time between difficulty changes have to get for us to make
changes?  In other words, if, at some point, block confirmation times are
averaging, say, hours or days, will we hardfork to speed things up?

One option is NO.  When enough economic interests align to amass the
computing power to get important bitcoin transactions into a block, then
they will work out a way to get that block confirmed.  This allows other
cryptocurrencies and technologies like LN to fill in.

There may be a group that will fork the code in order to adjust the
difficulty more rapidly, and bitcoin holders will put a value on
bitcoin-FDA ("Faster-Difficuly-Adjustment"), which is fine with me.  We can
learn how to fork peacefully from what we learned when BCH was born, and
what we learned when it split.

I think some insight into how core developers will handle increasing
demands to use faster difficulty adjustments (if they respond at all) will
be helpful, and this is why I'm asking.

Dave Scotese

[-- Attachment #2: Type: text/html, Size: 1220 bytes --]

             reply	other threads:[~2018-12-03 20:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-03 20:37 Dave Scotese [this message]
2018-12-05 14:08 ` [bitcoin-dev] How much is too much time between difficulty changes? Zawy

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='CAGLBAhdtXEjhZWavgytQAOuXUaJZc=ZQyvjB2KV-YczAh-H4WQ@mail.gmail.com' \
    --to=dscotese@litmocracy.com \
    --cc=bitcoin-dev@lists.linuxfoundation.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