MIME-Version: 1.0
In-Reply-To: <201603021514.36769.luke@dashjr.org>
References: <201603021456.15820.luke@dashjr.org>
	<B9C659DC-1954-45C2-B3E6-552A17CDD655@Janik.cz>
	<201603021514.36769.luke@dashjr.org>
Date: Wed, 2 Mar 2016 16:24:31 +0100
Message-ID: <CAJqsvLAZR9CmQ0=2heCFaF6Nb=91iQ+kUKtoq3eQ-gn_mVYpBw@mail.gmail.com>
From: =?UTF-8?B?SsOpcsOpbWllIER1Ym9pcy1MYWNvc3Rl?= <jeremie.dl@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Precedence: list

> BtcDrak tells me he has well-tested code for this in his altcoin
Could you be more explicit, which altcoin is that?

> I am unaware of any reason this would be controversial
Probably not until you get to the details of any proposal. What is
your exact proposal here? Algorithm? Parameters?
As you likely know a too short time window would be dangerous for
other reasons. Getting to an agreement as to what is reasonable or not
is not necessarily trivial.

Jeremie


2016-03-02 16:14 GMT+01:00 Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org>:
> On Wednesday, March 02, 2016 3:05:08 PM Pavel Jan=C3=ADk wrote:
>> > the network. This would result in a significantly longer block interva=
l,
>> > which also means a higher per-block transaction volume, which could
>> > cause the block size limit to legitimately be hit much sooner than
>> > expected.
>>
>> If this happens at all (the exchange rate of the coin can accomodate suc=
h
>> expectation),
>
> The exchange rate is not significantly influenced by these things.
> Historically, it seems fairly obvious that the difficulty has followed va=
lue,
> 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 expecte=
d
>> higher exchange rate).
>
> Depends on the hashrate drop, and tolerance for higher fees, both of whic=
h are
> largely unknown at this time. At least having code prepared for the negat=
ive
> scenarios in case of an emergency seems reasonable, even if we don't end =
up
> needing to deploy it.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev