path: root/3d/b73e847ac122219cc4e9389be57ba23d5bfbcb

Return-Path: <bram@chia.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A6E98D36
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Aug 2018 20:55:32 +0000 (UTC)
Received: by mail-wr1-f65.google.com with SMTP id n2-v6so9269031wrw.7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAAS2fgRo5k8yBKXub46q7SQutskPKPmv5sXPZcM5+E_yzW5_mQ@mail.gmail.com>
	<50DD20FF-A67E-4DEF-96AF-705B62894AA0@xbt.hk>
In-Reply-To: <50DD20FF-A67E-4DEF-96AF-705B62894AA0@xbt.hk>
From: Bram Cohen <bram@chia.net>
Date: Thu, 30 Aug 2018 13:55:17 -0700
Message-ID: <CAHUJnBBRDRNyWoJQ0jt_r5JzTwhg4edBhyDCFfa7ToiqxUSe-g@mail.gmail.com>
To: jl2012@xbt.hk, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr">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&#39;s only 1/2016 =
of all blocks so it doesn&#39;t really matter, but it&#39;s worth thinking =
about the principle. In general soft forks are better when they don&#39;t c=
ause orphaning on non-upgraded miners.<div><br></div><div>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&#39; 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&#39;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</div><div><br></div><div>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.</div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 25, 2018 at 5:10 AM John=
son Lau via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">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.<br>
<br>
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. <br>
<br>
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 &lt;=3D t &lt=
;=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.=
<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
&gt; On 21 Aug 2018, at 4:14 AM, Gregory Maxwell via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; <br>
&gt; Since 2012 (IIRC) we&#39;ve known that Bitcoin&#39;s non-overlapping<b=
r>
&gt; difficulty calculation was vulnerable to gaming with inaccurate<br>
&gt; timestamps to massively increase the rate of block production beyond<b=
r>
&gt; the system&#39;s intentional design. It can be fixed with a soft-fork =
that<br>
&gt; further constraints block timestamps, and a couple of proposals have<b=
r>
&gt; been floated along these lines.<br>
&gt; <br>
&gt; I put a demonstration of timewarp early in the testnet3 chain to also<=
br>
&gt; let people test mitigations against that.=C2=A0 It pegs the difficulty=
 way<br>
&gt; down and then churned out blocks at the maximum rate that the median<b=
r>
&gt; time protocol rule allows.<br>
&gt; <br>
&gt; I, and I assume others, haven&#39;t put a big priority into fixing thi=
s<br>
&gt; vulnerability because it requires a majority hashrate and could easily=
<br>
&gt; be blocked if someone started using it.<br>
&gt; <br>
&gt; But there haven&#39;t been too many other network consensus rules goin=
g on<br>
&gt; right now, and I believe at least several of the proposals suggested<b=
r>
&gt; are fully compatible with existing behaviour and only trigger in the<b=
r>
&gt; presence of exceptional circumstances-- e.g. a timewarp attack.=C2=A0 =
So<br>
&gt; the risk of deploying these mitigations would be minimal.<br>
&gt; <br>
&gt; Before I dust off my old fix and perhaps prematurely cause fixation on=
<br>
&gt; a particular approach, I thought it would be useful to ask the list if=
<br>
&gt; anyone else was aware of a favourite backwards compatible timewarp fix=
<br>
&gt; proposal they wanted to point out.<br>
&gt; <br>
&gt; Cheers.<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000a2cb650574ad4b50--