From: David Manheim <davidmanheim@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Proposing a (potentially less contentious) difficulty drop solution
Date: Fri, 4 Mar 2016 11:38:59 -0800 [thread overview]
Message-ID: <CAMsFVXnfLf5L4oMCCnydNsUK2M9=KbAX5syV5x8iKgWHz=C_hQ@mail.gmail.com> (raw)
Hi all,
I've been following this discussion closely. Unlike most of the
developers, I'm more of an economist and game theorist than
cryptographer, and I wanted to suggest a possible compromise solution.
Brief review of discussion so far, as background;
There is a clear split in the discussion on the list about the costs
and benefits of a potential solution. Most of this is because of
implicit disagreement about the probability of a stalled blockchain at
the halving, and how a change would open the door to worries about
future changes. That said, as Paul Sztorc noted, "This
halving-difficulty-drop problem can, with some bad luck, get quite
disastrous, very quickly." If it doesn't happen, however, the
solutions proposed unfairly give a bonus to miners, and speeding up
the chain for a while - which also potentially increases the odds of
block-splits during that time.
Lukejr suggested that "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)." That means it would fork after the
halving, if and only if there was a stall. The problem with this is to
detect it, and how to retarget, given asynchronous nodes. I don't
think this can be avoided nicely without either creating some
perverse incentives, or handing a large bonus to miners. Paul suggests
a very low retarget difficulty, which essentially gives a larger bonus
to miners until the next retarget; that's non-ideal. He also suggests
investigating dynamic retargeting, (This was proposed a while ago
here: http://www.truthcoin.info/blog/mining-heart-attack/ ) which
others note is unfairly changing the implicit contract.
The methods implemented by many altcoins with smooth / dynamic
retargeting are not really suitable directly - as noted, people didn't
sign up for dynamic retargeting, and there are stability issues. If
bitcoin's hash rate drops after the halving, it could be sudden and
drastic. Any solution I can foresee that prevents this leads to some
difficult to analyze incentives for the miners.
My proposal:
I think a simple solution splits the difference; a short temporary
dynamic difficulty retargeting after the halving. This allows for a
fix, while making it clear that the original ruless of bitcoin
shouldn't be discarded, and when they need to be altered, it will be a
minimal change. It also limits the period where perverse incentives
can exist, which minimizes their effects.
We don't know what difficultly is appropriate after the halving, but
can still allow a temporary dynamic difficult retargeting starting
then. Halving occurs at block 420,000; it will then be 1/3 of the way
to the next difficulty retarget. The remaining 1344 of those 2016
blocks can be used for a dynamic retarget, without changing the
schedule otherwise. The initial retarget difficulty would be 1/2 of
the previous one, as suggested by others, but it would very quickly
stabilize at the appropriate level, using essentially any dynamic
method - and so it would not stay low for long, unless necessary. One
potential downside is that the probability of a orphaned blocks
increases for a couple blocks. (That seems inevitable with any method
that might reduce difficulty and lead to faster block generation, but
by retargeting quickly, we limit that time frame.) At block 421344, it
reverts to using the current method - and that can use the entire last
2016 blocks, to smooth out the lower difficulty adjustment that
occurred.
(Conveniently, in the longer term, the same method could be used for
the 3 halvings after this one, with correspondingly shorter retarget
windows, since 210000 isn't divisible by 2016 - until we're down to
the 1.25btc coinbase reward, with 336 blocks until the next retarget.
The next halving could eliminate this; the coinbase reward would be
much less than mining fees by then, and halving difficulty would be
unneeded. This also means that the retarget about would be reduced in
the subsequent 2016 blocks each time, since the smaller retarget
window will still be averaged in with the earlier blocks.)
The only remaining question is what temporary retargeting method
should we use? I'm completely agnostic on this one, since I think it
doesn't make a huge difference, as long as there is a method chosen.
Short altcoin methods review, to make some options clear;
Smooth difficulty readjustment methods have been implemented by many
altcoins. The first of these seems to be Kimoto Gravity Well, which
does smoothing as follows; KGW = 1 + (0.7084 *
pow((double(PastBlocksMass)/double(144)), -1.228)); DigiByteCoin
tested this in the presence of discontinuities, and found it responded
too slowly. Instead, they created the so-called Digishield, which was
created explicitly to do smoothing in the presence of sudden shifts in
mining, without causing stalling - but uses much closer together
blocks to do so. See:
https://www.reddit.com/r/Digibyte/comments/1yn6t1/digibyte_v_20_code_name_digishield/
for more. Another such method is Heavycoin's temporal retargeting. Any
of these should be fine, since we don't need such fast response times.
I hope this is a useful potential compromise,
David Manheim
reply other threads:[~2016-03-04 19:39 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='CAMsFVXnfLf5L4oMCCnydNsUK2M9=KbAX5syV5x8iKgWHz=C_hQ@mail.gmail.com' \
--to=davidmanheim@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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