From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	shaolinfry <shaolinfry@protonmail.ch>
Date: Wed, 5 Jul 2017 03:50:51 +0000
User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.32; x86_64; ; )
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
In-Reply-To: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201707050350.53122.luke@dashjr.org>
Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
Precedence: list

I've already opened a PR almost 2 weeks ago to do this and fix the other 
issues BIP 9 has. https://github.com/bitcoin/bips/pull/550

It just needs your ACK to merge.


On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable
> to miners fiddling with timestamps in a way that could prevent or delay
> activation - for example by only advancing the block timestamp by 1 second
> you would never meet the threshold (although this would come a the penalty
> of hiking the difficulty dramatically). On the other hand, the exact date
> of a height based thresholds is hard to predict a long time in advance due
> to difficulty fluctuations. However, there is certainty at a given block
> height and it's easy to monitor. If there is sufficient interest, I would
> be happy to amend BIP8 to be height based. I originally omitted height
> based thresholds in the interests of simplicity of review - but now that
> the proposal has been widely reviewed it would be a trivial amendment.