From: Luke Dashjr <luke@dashjr.org>
To: Pavel =?utf-8?q?Jan=C3=ADk?= <Pavel@janik.cz>
Date: Wed, 2 Mar 2016 15:14:35 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.8; x86_64; ; )
References: <201603021456.15820.luke@dashjr.org>
	<B9C659DC-1954-45C2-B3E6-552A17CDD655@Janik.cz>
In-Reply-To: <B9C659DC-1954-45C2-B3E6-552A17CDD655@Janik.cz>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201603021514.36769.luke@dashjr.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Precedence: list

On Wednesday, March 02, 2016 3:05:08 PM Pavel Jan=C3=ADk wrote:
> > 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.
>=20
> If this happens at all (the exchange rate of the coin can accomodate such
> expectation),

The exchange rate is not significantly influenced by these things.=20
Historically, it seems fairly obvious that the difficulty has followed valu=
e,=20
not value following difficulty.

> the local fee market will develop, fees will raise and complement mined
> coins, thus bringing more miners back to the game (together with expected
> higher exchange rate).

Depends on the hashrate drop, and tolerance for higher fees, both of which =
are=20
largely unknown at this time. At least having code prepared for the negativ=
e=20
scenarios in case of an emergency seems reasonable, even if we don't end up=
=20
needing to deploy it.

Luke