Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A6E98D36 for ; Thu, 30 Aug 2018 20:55:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 42549800 for ; Thu, 30 Aug 2018 20:55:32 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id n2-v6so9269031wrw.7 for ; Thu, 30 Aug 2018 13:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=StOOVdq47hT0tTnKedcuJ0oPX+PFrAPyR4WmDRODgQ8=; b=ri5CZRspFFwHnVB/5W/saeJEqWaSDDEjyVimAXoAtFqV43rKUiemx8xQPHdp0SQ3TK z5ZWPmTe4F4GpxApza7CuRDt5h2VcfOuhpD7Rz4F32fSn4RuIjYa/CJKl5oImzOFxIIZ SkFCqGq9vGCoPb9kOWgkYNy920UZ3I6ViQXTsONM+JZaEklyGJSeRhjMVgN8oQLq4Nrn ErWlSnzOxlPTyitDTdEUPBXxXmDscS7IsAKAZtztjJjcR/DrRTa1O2F9zB3wWKO7anuM O5sOeyJBxcM4sZC4OmRzSSBjY3ZDZH0diuGT09dWRGME3H6Nh+GTitnkyNPPAbP/8UAj dlMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=StOOVdq47hT0tTnKedcuJ0oPX+PFrAPyR4WmDRODgQ8=; b=AmOobiNYSFa+VAppsWGo5jTRH4u/Jgs8VbiaPtAqZWSrodjY+9coIkudQSnH5wyQet UN/hGEzClcuTNynKDwLexE4BNoB/V449yoigP8TK74kkFdnocHjtpjLN6dhXeq5SNx0z FpLjf/xdGDN/5IucaZRlqV4e+oy98EPkZaNNP2UtIcJlWvdOcLnQosbz7IRosexcyY8E D/CSk7kkQYSCmGW2dbK2Ix/hyIV4UC/MLNSHvq7ebvTOrY18rjL8YaPXgyZSfecDK0ub t5xKm3J8DvlHVGJ7U71KKADuHEYB3A5K1P4oSF66FpFCnPW7ET+lXU+nDPaZ/sFJys/h i9CQ== X-Gm-Message-State: APzg51Baad4ykS4Tqzh0HRcdBR9RsTKn50IPTlkCM5VKj0BQvxS0Yqep +w2MkhKcizJIZPbPc/yZqHNXuqRrNyD16eQj/UGmDUQ1 X-Google-Smtp-Source: ANB0VdaPvCCHiF7IOeCsul7Dad4zGR3NN63RMBravOCqSQJtzX3T0/QLhfvkQZp6Q9Xs2yK/UTAbcifKuimW0iBvvfE= X-Received: by 2002:adf:9142:: with SMTP id j60-v6mr8792310wrj.180.1535662530671; Thu, 30 Aug 2018 13:55:30 -0700 (PDT) MIME-Version: 1.0 References: <50DD20FF-A67E-4DEF-96AF-705B62894AA0@xbt.hk> In-Reply-To: <50DD20FF-A67E-4DEF-96AF-705B62894AA0@xbt.hk> From: Bram Cohen Date: Thu, 30 Aug 2018 13:55:17 -0700 Message-ID: To: jl2012@xbt.hk, Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a2cb650574ad4b50" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 30 Aug 2018 23:18:13 +0000 Subject: Re: [bitcoin-dev] Getting around to fixing the timewarp attack. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 20:55:33 -0000 --000000000000a2cb650574ad4b50 Content-Type: text/plain; charset="UTF-8" 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 > --000000000000a2cb650574ad4b50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This seems like a case where a distinction should be made = between soft forks which are likely to cause non-upgraded miners to get orp= haned 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 c= ause 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 &#= 39;close enough' together sounds like a solid approach. Given that bloc= ks 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 backwar= ds jump of that plus some safety parameter. Let's say three hours. It a= lso feels like a good idea to not allow a jump of more than three hours for= wards either, just on principle.=C2=A0

That should= result in minimal code changes, and rarely any orphaning of non-upgraded m= iners 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 thre= e hours out of every two weeks seems like no big deal.

On Sat, Aug 25, 2018 at 5:10 AM John= son 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) inst= ead.

A naive but perfect fix is to require every block (2016x) to have a timesta= mp not smaller than that of its parent block. However, a chain-split would = happen even without any attack, unless super-majority of miners are enforci= ng 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 <=3D t <= ;=3D infinity. With a bigger t, the fix is less effective but also less lik= ely 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 smal= l-enough-to-prohibit-time-wrap-attack but also big-enough-to-avoid-split. W= ith 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 t= ry to rewrite 24 hours of history. Such scale of 51% attack is already abov= e 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 t= he protocol limit for using a future timestamp) at the exact moment of reta= rget. That means no retarget is possible in the next 2016 blocks. Doing a t= ime-wrap attack at this point is not quite interesting as the coin is proba= bly already worthless. Again, this is a much bigger problem than the potent= ial chain spilt. People will yell for a difficulty (and time wrap fix, mayb= e) hardfork to resuscitate the chain.




> On 21 Aug 2018, at 4:14 AM, Gregory Maxwell via bitcoin-dev <bitcoi= n-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<= br> > let people test mitigations against that.=C2=A0 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 thi= s
> 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 goin= g 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.=C2=A0 = 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/mail= man/listinfo/bitcoin-dev
--000000000000a2cb650574ad4b50--