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 general soft forks are better when they don't cause orphaning on
non-upgraded miners.

The whole problem seems to be caused by the difference between the
timestamps at the end of a period and the block right after it. Soft
forking to force those to be 'close enough' together sounds like a solid
approach. Given that blocks are generally send around fairly quickly, and
that blocks more than two hours in the future are ignored, it seems
reasonable to not allow a backwards jump of that plus some safety
parameter. Let's say three hours. It also feels like a good idea to not
allow a jump of more than three hours forwards either, just on principle.

That should result in minimal code changes, and rarely any orphaning of
non-upgraded miners at all, and still only 1/2016 blocks when they do. And
no trace of a hard fork. It suffers from still allowing the attack a little
bit, but three hours out of every two weeks seems like no big deal.

On Sat, Aug 25, 2018 at 5:10 AM Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 than that of its parent block. However, a chain-split
> would happen even without any attack, unless super-majority of miners are
> enforcing the new rules. This also involves mandatory upgrade of pool
> software (cf. pool software upgrade is not mandatory for segwit). The best
> way is to do it with something like BIP34, which also requires new pool
> software.
>
> We could have a weaker version of this, to require the timestamp of block
> (2016x) not smaller than its parent block by t-seconds, with 0 <= t <=
> infinity. With a bigger t, the fix is less effective but also less likely
> to cause intentional/unintentional split. Status quo is t = infinity.
>
> Reducing the value of t is a softfork. The aim is to find a t which is
> small-enough-to-prohibit-time-wrap-attack but also
> big-enough-to-avoid-split. With t=86400 (one day), a time-wrap attacker may
> bring down the difficulty by about 1/14 = 7.1% per round. Unless new blocks
> were coming incredibly slow, the attacker needs to manipulate the MTP for
> at least 24 hours, or try to rewrite 24 hours of history. Such scale of 51%
> attack is already above the 100-block coinbase maturity safety theshold and
> we are facing a much bigger problem.
>
> With t=86400, a non-majority, opportunistic attacker may split the chain
> only if we have no new block for at least 24 - 2 = 22 hours (2-hours is the
> protocol limit for using a future timestamp) at the exact moment of
> retarget. That means no retarget is possible in the next 2016 blocks. Doing
> a time-wrap attack at this point is not quite interesting as the coin is
> probably already worthless. Again, this is a much bigger problem than the
> potential chain spilt. People will yell for a difficulty (and time wrap
> fix, maybe) hardfork to resuscitate the chain.
>
>
>
>
> > On 21 Aug 2018, at 4:14 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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 timestamps, and a couple of proposals have
> > been floated along these lines.
> >
> > I put a demonstration of timewarp early in the testnet3 chain to also
> > let people test mitigations against that.  It pegs the difficulty way
> > down and then churned out blocks at the maximum rate that the median
> > time protocol rule allows.
> >
> > I, and I assume others, haven't put a big priority into fixing this
> > vulnerability because it requires a majority hashrate and could easily
> > be blocked if someone started using it.
> >
> > But there haven't been too many other network consensus rules going on
> > right now, and I believe at least several of the proposals suggested
> > are fully compatible with existing behaviour and only trigger in the
> > presence of exceptional circumstances-- e.g. a timewarp attack.  So
> > the risk of deploying these mitigations would be minimal.
> >
> > Before I dust off my old fix and perhaps prematurely cause fixation on
> > a particular approach, I thought it would be useful to ask the list if
> > anyone else was aware of a favourite backwards compatible timewarp fix
> > proposal they wanted to point out.
> >
> > Cheers.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>