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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8CCECE42
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Aug 2018 20:15:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com
[209.85.222.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB409774
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Aug 2018 20:15:03 +0000 (UTC)
Received: by mail-ua1-f41.google.com with SMTP id i4-v6so10518518uak.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Aug 2018 13:15:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=unEweeDR9odJZSRjZ6oEtTg8Usfaylf8M1xwn5/5veE=;
b=ZYCl5TqQqSLHkfu0HXdNxyBcTdfTt+NKuXb9uzD3RmRWgCazF/RwzwKQ87LKffVrUg
crYM2EFSRX930ce8VVL3mMOSYTR6YeQ6lb7RTmVC3nLX2WPYDUrRa/PP6Rkoif7af8m7
P9WD9p4glaqBAfBXUagtZEv7qs//pKkrwvqqoKliiaO7dAX7lJ8yFBG3FnNzJsAAnVic
1Y85efGRsjM6w86LSwdu8y1xGd/DukHFFR22rAnVGGlK58ozvZVfgcvOKWg0/JvBFum9
vvYFw0qu+yBa/RBwNYSPT2ocbzVPki2+l9c1PG47DssveyHsvR3wIuD7jAdCHk04A3wY
WegQ==
X-Gm-Message-State: AOUpUlGxrG7eOWBpvY6cdmaIGulK/dMzMitZBt4VF9b5xzM9+VQxKzuw
ztl1DmrUsWZMK+s/BSozu5IFnD0k2w0MjoJT2zhuww==
X-Google-Smtp-Source: AA+uWPx2a7IWimc2F0Jjp8Ipq+e0YaitF+D5EPq/oReVQ5EmriowGdaSzaiswlTMhreDUq3Hn94dZOjq81D5z9PT7xg=
X-Received: by 2002:ab0:1544:: with SMTP id
p4-v6mr31189888uae.81.1534796102596;
Mon, 20 Aug 2018 13:15:02 -0700 (PDT)
MIME-Version: 1.0
From: Gregory Maxwell <greg@xiph.org>
Date: Mon, 20 Aug 2018 20:14:50 +0000
Message-ID: <CAAS2fgRo5k8yBKXub46q7SQutskPKPmv5sXPZcM5+E_yzW5_mQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
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: Mon, 20 Aug 2018 21:10:48 +0000
Subject: [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: Mon, 20 Aug 2018 20:15:06 -0000
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.
|
