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
|
Return-Path: <wordsgalore@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9E1A7255
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 May 2019 17:40:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com
[209.85.217.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 101C15E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 May 2019 17:40:27 +0000 (UTC)
Received: by mail-vs1-f46.google.com with SMTP id q64so6663806vsd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 May 2019 10:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=wLUgULmEKOvSkLfbTU0VJa03Qwk/6197mOH6cR6XHY4=;
b=H+H1tLiTR/dl2gq26j+ljoaU5F3eR1iE8Wr37iQdIG7rHNPPYkz3os9q/xnHrGOrpM
IU2ufcNYKXXc4YlxTXRGRYgikgDVS1bkZkWFTVw8ANbvee6JwpRfzkN5pl6VrBqJ1dcZ
oQgeRl8EViXK8oi4QBk0VAcEQ5HQNQ1srNPZDp+2Vrwqz/exyJS3kWbsfr7UWBKu/dLn
FNTeBmEpQo7Ze2SMC4hYGTPtLSTfo35kJRqr14U25TJAK40+2Y1PuysEScHBsEfTn/Fl
usQdfnkymW+0DXBYQQnZc9hw/iTBsYhx4YpkTiJos6k8IOBvT6k++z2Dv0Wkp4SdCAVM
jI2g==
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=wLUgULmEKOvSkLfbTU0VJa03Qwk/6197mOH6cR6XHY4=;
b=EBT9OCug1CaYXcl5ez/9pGanCM8Yoh1t+Qds/6/CQvSLLEvUHAUiu2QiZZ+UBnO16C
KzQW6ezFL+W8xWSpQ599uLnqSp8SMfTfbRdEbQf4rkRD0F1vxtK7SVWH8kFD9CXy/Zt1
8x8oIt6cHrPVXWLTPK7JUszKokW+I0haQIhqk8mxYOWXtDDZAGhAVv33T651mcspIhLA
V052JFJrjyOnFAQdkVECUVQj9KZXOkilOD0sJFUuHor9e6L9sspZ6CNYTtgb2JIyKIVe
2TE1BnzYDQuGraxBJSl5ukdmPDanVTUK3pKXyJfOrlaLvLJYJtZ2iZbzE2ZfYMhQp3t2
bNvw==
X-Gm-Message-State: APjAAAWcXkXiVY+789o+qCL8ILtuzY+oA31LPPIPjfW43kCOfb7NpLYY
s8LMWJJ++b+kdNYDddHLy8Yn/QJcoDnRFf1JYvAIAMaL
X-Google-Smtp-Source: APXvYqx3pC/LeHT5zcm6XzI34r77P3hKtlTXG/8zruWeYzwkE2h9zsGssWZVPPpvN8yybYeX1BiP7BREuJxQfmKKGD8=
X-Received: by 2002:a67:fd93:: with SMTP id k19mr17149843vsq.45.1558201226851;
Sat, 18 May 2019 10:40:26 -0700 (PDT)
MIME-Version: 1.0
From: Zawy <wordsgalore@gmail.com>
Date: Sat, 18 May 2019 13:40:16 -0400
Message-ID: <CADtTMv=H1rqfspx4=r+TDqxWVOXRO5yROzTuo0go6vtpevEJDQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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: Sat, 18 May 2019 17:51:17 +0000
Subject: [bitcoin-dev] Code not following proof of security
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: Sat, 18 May 2019 17:40:28 -0000
If MAX_FUTURE_BLOCK_TIME in chain.h is set smaller than
DEFAULT_MAX_TIME_ADJUSTMENT in timedata.h, the POW security can be
undermined by a 33% Sybil attack on the nodes. Blocks with accurate
timestamps would be rejected which allows various attacks. Code should
reflect a proof of security, so it should be coded as
DEFAULT_MAX_TIME_ADJUSTMENT = MAX_FUTURE_BLOCK_TIME / 2
(or sufficiently commented) otherwise future developers could make a
change that hurts security. "Unintended consequences due to how
disparate code interacts" is the result of code not following a proof
of security. I came across this while trying to "derive" POW security
from within Lamport's 1982 framework. The problem is that POW security
requires clock synchronization. But using median of network time for
it is a consensus mechanism that is subject to Byzantine attacks. So
POW requires an absolute bound on time (enforced by an oracle) that is
at least as stringent as the allowed timestamp variation. The rule
to revert to node time if network time is >70 minutes off is the real
bound that honest nodes can impose unilaterally, limiting the
potential damage of consensus (if MAX_FUTURE_BLOCK_TIME is not too
small). This fail-safe uses node operators as the oracle, who can all
approximately agree as to what time it is without asking each other. A
>50% Sybil attack on nodes fails because an honest new node joining
can unilaterally reject the chain if the current timestamp is not
realistic. Cryptonote appears to have done away with network time
without ill effect. The only other option to "the node operator is the
oracle" is to assume all internal clocks have a max drift, but this
would disconnect timestamps from real time to the extent of that drift
(if I'm reading Halpern, etc 1984 IBM correctly). I'm assuming Mike
Hearn was wrong in saying the centralization of NTP (or GPS) is
acceptable:
https://bitcointalk.org/index.php?topic=10241.msg148084#msg148084
This affects coins who reduced MAX_FUTURE_BLOCK_TIME without either
removing the time consensus mechanism or reducing the
DEFAULT_MAX_TIME_ADJUSTMENT. Many have done this in order to have
faster responding difficulty algorithms, otherwise a large
MAX_FUTURE_BLOCK_TIME allows a sizable manipulation of difficulty.
Therefore, MAX_FUTURE_BLOCK_TIME should itself should be a function of
the size of the difficulty window for proof of security (instead of a
constant). I suspect more constants = less proof of security. For
example
MFBT = WindowTimespan / 10 would limit timestamp manipulation to 10% per window.
|
