From: Johnson Lau <jl2012@xbt.hk>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Fri, 24 Aug 2018 17:35:11 +0800
References: <CAAS2fgRo5k8yBKXub46q7SQutskPKPmv5sXPZcM5+E_yzW5_mQ@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAAS2fgRo5k8yBKXub46q7SQutskPKPmv5sXPZcM5+E_yzW5_mQ@mail.gmail.com>
Message-Id: <50DD20FF-A67E-4DEF-96AF-705B62894AA0@xbt.hk>
Subject: Re: [bitcoin-dev] Getting around to fixing the timewarp attack.
Precedence: list

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.=20

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 <=3D =
t <=3D infinity. With a bigger t, the fix is less effective but also =
less likely to cause intentional/unintentional split. Status quo is t =3D =
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=3D86400 (one day), a time-wrap =
attacker may bring down the difficulty by about 1/14 =3D 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=3D86400, a non-majority, opportunistic attacker may split the =
chain only if we have no new block for at least 24 - 2 =3D 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.

=20


> On 21 Aug 2018, at 4:14 AM, Gregory Maxwell via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Cheers.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev