1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 83E13BBD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Aug 2018 09:50:23 +0000 (UTC)
X-Greylist: delayed 00:15:03 by SQLgrey-1.7.6
Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DB2C22C3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Aug 2018 09:50:22 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1535103316; cv=none; d=zoho.com; s=zohoarc;
b=QYwYbs2SiVd0zgrK3EsCohl1Vn1UUDshxrkQd89eUUfMjoSSFCnZk4iwUxWtIRMqYClBNuj71itWoKI+xk93QWxH/YMiRD612VY8mGb6FObJkeaOwdgDGugE8BcFtdZTE1ElA67L3zNHW6/aR/i8eVoeCIwNkzx3UcEIh5Zraug=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1535103316;
h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=MwFac5IQ9l2nIuZL52al4QMBqOsZZQxtb2jB3/5cTPQ=;
b=hx9xa2XdXEAJFSlAdAzzxkFrnmbGOkHnpEQH/greYvWK1KOFjZBftvauRPWT50peOP1nD3ltaXHh0o1LBAeD+FNwgm5EmNLJjPykNl0DUNggXIUkyVIO14QhbV1WJko9A+7P5ZsKAoiykzN/Xe9uMhtOPhE7vWABVzLRLyslREo=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk;
spf=pass smtp.mailfrom=jl2012@xbt.hk;
dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.8.0.103] (n218103136198.netvigator.com [218.103.136.198])
by mx.zohomail.com with SMTPS id 1535103314520453.2628338877438;
Fri, 24 Aug 2018 02:35:14 -0700 (PDT)
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>
X-Mailer: Apple Mail (2.3445.8.2)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Sat, 25 Aug 2018 12:10:20 +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: Fri, 24 Aug 2018 09:50:23 -0000
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
|
