This seems like a case where a distinction should be made between soft
forks which are likely to cause non-upgraded miners to get orphaned and
ones where they are. Of course in this case it's only 1/2016 of all blocks
so it doesn't really matter, but it's worth thinking about the principle.
In
Rather than restricting every timestamp (or just the 2016*N+1
timestamps) to >= 1+ the previous timestamp as recorded on the
blockchain, the difficulty calculation could have the same restriction
but only in how the timestamps are used. I don't know about backwards
compatibility. Either way, this
To determine the new difficulty, it is supposed to compare the timestamps of
block (2016n - 1) with block (2016n - 2017). However, an off-by-one bug makes
it compares with block (2016n - 2016) instead.
A naive but perfect fix is to require every block (2016x) to have a timestamp
not smaller
I only knew about ArtForz's fix, which isn't backwards compatible.
https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki#code
On Mon, Aug 20, 2018 at 10:14 PM, Gregory Maxwell via bitcoin-dev
wrote:
>
Since 2012 (IIRC) we've known that Bitcoin's non-overlapping
difficulty calculation was vulnerable to gaming with inaccurate
timestamps to massively increase the rate of block production beyond
the system's intentional design. It can be fixed with a soft-fork that
further constraints block