MIME-Version: 1.0
In-Reply-To: <201603021456.15820.luke@dashjr.org>
References: <201603021456.15820.luke@dashjr.org>
Date: Wed, 2 Mar 2016 10:17:31 -0600
Message-ID: <CABaSBazpdSMJLf-pbiZ45HJycKVcGG2iqs98E5BeJyqPGZfpTg@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary=089e0160b7c60a532f052d133877
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Precedence: list

--089e0160b7c60a532f052d133877
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 2, 2016 at 8:56 AM, Luke Dashjr wrote:

> We are coming up on the subsidy halving this July, and there have been so=
me
>

Luke,

One reason "hard-fork to fix difficulty drop algorithm" could be
controversial is that the proposal involves a hard-fork (perhaps
necessarily so, at my first and second glance). There are a number of
concerns with hard-forks including security, deployment, participation,
readiness measurement, backwards incompatibility, etc. In fact, some
Bitcoin Core developers believe that hard-forks are not a good idea and
should not be used.

# Hard-forks

An interesting (unspoken?) idea I=E2=80=99ve heard from a few people has be=
en =E2=80=9Cwe
should try to avoid all hard-forks because they are backwards
incompatible=E2=80=9D, another thought has been "there should only be one m=
ore
hard-fork if any" and/or "there should only be one hard-fork every 30
years". I also recognize feedback from others who have mentioned "probably
unrealistic to expect that the consensus layer can be solidified this early
in Bitcoin's history". At the same time there are concerns about =E2=80=9Cs=
lippery
slopes=E2=80=9D....

Also, if you are going to participate in a hard-fork then I think you
should make up some proposals for ensure minimal monetary loss on the old
(non-hard-forked) chain, especially since your proposed timeline is so
short seems reasonable to expect even more safety-related due diligence to
minimize money loss (such as using a new address prefix on the hard-forked
upgrade). Anyway, it should be clear that hard-forks are an unsettled issue
and are controversial in ways that I believe you are already aware about.

# Have miners gradually reduce their hashrate instead of using a step
function cliff

adam3us recently proposed that miners who are thinking of turning off
equipment should consider gradually ramping down their hashrate, as a show
of goodwill (and substantial loss to themselves, similar to how they would
incur losses from no longer mining after the halving). This is not
something the consensus algorithm can enforce at the moment, and this
suggestion does not help under adversarial conditions. Since this
suggestion does not require a hard-fork, perhaps some effort should be made
to query miners and figure out if they need assistance with implementing
this (if they happen to be interested).

# Contingency planning

Having said all of the negative things above about hard-forks, I will add
that I do actually like the idea of having backup plans available and
tested and gitian-built many weeks ahead of expected network event dates.
Unfortunately this might encourage partial consensus layer hard-forks in
times of extreme uncertainty such as "emergencies".... creating an even
further emergency.

# "Indefinite backlog growth"

You write "the backlog would grow indefinitely until the adjustment
occurs". This seems to be expected behavior regardless of difficulty
adjustment (in fact, a backlog could continue to grow even once difficulty
adjusts downward), and the consensus protocol does not commit to
information regarding that backlog anyway...

# Difficulty adjustment taking time is expected

This is an expected part of the protocol, it's been mentioned since
forever, it's well known and accounted for. Instead, we should be providing
advice to users about which alternative payment systems they should be
using if they expect instantaneous transaction confirmations. This has been
a long-standing issue, and rolling out a hard-fork is not going to fix
mistaken assumptions from users. They will still think that confirmations
were meant to be instantaneous regardless of how many hard-forks you choose
to deploy.

- Bryan
http://heybryan.org/
1 512 203 0507

--089e0160b7c60a532f052d133877
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 2, 2016 at 8:56 AM, Luke Dashjr wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We are c=
oming up on the subsidy halving this July, and there have been some<br></bl=
ockquote><div><br><div>Luke,</div><div><br></div><div>One reason &quot;hard=
-fork to fix difficulty drop algorithm&quot; could be controversial is that=
 the proposal involves a hard-fork (perhaps necessarily so, at my first and=
 second glance). There are a number of concerns with hard-forks including s=
ecurity, deployment, participation, readiness measurement, backwards incomp=
atibility, etc. In fact, some Bitcoin Core developers believe that hard-for=
ks are not a good idea and should not be used.</div><div><br></div><div># H=
ard-forks</div><div><br></div><div>An interesting (unspoken?) idea I=E2=80=
=99ve heard from a few people has been =E2=80=9Cwe should try to avoid all =
hard-forks because they are backwards incompatible=E2=80=9D, another though=
t has been &quot;there should only be one more hard-fork if any&quot; and/o=
r &quot;there should only be one hard-fork every 30 years&quot;. I also rec=
ognize feedback from others who have mentioned &quot;probably unrealistic t=
o expect that the consensus layer can be solidified this early in Bitcoin&#=
39;s history&quot;. At the same time there are concerns about =E2=80=9Cslip=
pery slopes=E2=80=9D....</div><div><br></div><div>Also, if you are going to=
 participate in a hard-fork then I think you should make up some proposals =
for ensure minimal monetary loss on the old (non-hard-forked) chain, especi=
ally since your proposed timeline is so short seems reasonable to expect ev=
en more safety-related due diligence to minimize money loss (such as using =
a new address prefix on the hard-forked upgrade). Anyway, it should be clea=
r that hard-forks are an unsettled issue and are controversial in ways that=
 I believe you are already aware about.</div><div><br></div><div># Have min=
ers gradually reduce their hashrate instead of using a step function cliff<=
/div><div><br></div><div>adam3us recently proposed that miners who are thin=
king of turning off equipment should consider gradually ramping down their =
hashrate, as a show of goodwill (and substantial loss to themselves, simila=
r to how they would incur losses from no longer mining after the halving). =
This is not something the consensus algorithm can enforce at the moment, an=
d this suggestion does not help under adversarial conditions. Since this su=
ggestion does not require a hard-fork, perhaps some effort should be made t=
o query miners and figure out if they need assistance with implementing thi=
s (if they happen to be interested).</div><div><br></div><div># Contingency=
 planning</div><div><br></div><div>Having said all of the negative things a=
bove about hard-forks, I will add that I do actually like the idea of havin=
g backup plans available and tested and gitian-built many weeks ahead of ex=
pected network event dates. Unfortunately this might encourage partial cons=
ensus layer hard-forks in times of extreme uncertainty such as &quot;emerge=
ncies&quot;.... creating an even further emergency.</div><div><br></div><di=
v># &quot;Indefinite backlog growth&quot;</div><div><br></div><div>You writ=
e &quot;the backlog would grow indefinitely until the adjustment occurs&quo=
t;. This seems to be expected behavior regardless of difficulty adjustment =
(in fact, a backlog could continue to grow even once difficulty adjusts dow=
nward), and the consensus protocol does not commit to information regarding=
 that backlog anyway...</div><div><br></div><div># Difficulty adjustment ta=
king time is expected</div><div><br></div><div>This is an expected part of =
the protocol, it&#39;s been mentioned since forever, it&#39;s well known an=
d accounted for. Instead, we should be providing advice to users about whic=
h alternative payment systems they should be using if they expect instantan=
eous transaction confirmations. This has been a long-standing issue, and ro=
lling out a hard-fork is not going to fix mistaken assumptions from users. =
They will still think that confirmations were meant to be instantaneous reg=
ardless of how many hard-forks you choose to deploy.</div><div><br></div></=
div></div><div class=3D"gmail_signature">- Bryan<br><a href=3D"http://heybr=
yan.org/" target=3D"_blank">http://heybryan.org/</a><br>1 512 203 0507</div=
>
</div></div>

--089e0160b7c60a532f052d133877--