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
|
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 B25301036
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jan 2018 21:54:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com
[209.85.213.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9E5E51CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jan 2018 21:54:24 +0000 (UTC)
Received: by mail-vk0-f48.google.com with SMTP id z9so5515666vkd.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Jan 2018 13:54:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=GOla6OsGnStk4gFqzsaiuxvc4eDbRXozci85iB44yLs=;
b=LXN+MYij2VL5FYUN+YBi3s9jFhavqnppd95AGfsJSZP5T7nj2EpibRa4cx5cy7wCy4
f6xMdIv7g7ipNCyT1KC/DyDDh+ZphAAmXFkhjA//zTjFWfssDWa8V/fmXma0oSwzM21C
BFlc+e4HaJOhZ6DwBXO4DYeGdBmykl6JNp688JSvo58FNDvZjxFB0ShOjUM05ZroOiQY
6SqZTkT8sXwnxK5r2dJoK0xVYtFMo8efPtR0qJQk85MfkxMltKz7cLPZG96GjPKlDGzi
hgUtll5xmkSDNyXfLX08E51lroY0NQhgVs+zztW6umKr8EGod8b+3USP62IM7bIKTWsf
PY8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=GOla6OsGnStk4gFqzsaiuxvc4eDbRXozci85iB44yLs=;
b=bGbKwhKLCLV+QKgn881xPsNDxgdi2poavDN5QTi+vBUWf+ThejPVB22gH8V0MSURg3
mxriDn5Nn4VTjyt1iOlNYKf+iEcuf9zzyypwpFM3OiB3bKzmP9ayYpzbExW6SGqPZyFl
ENvkZ4Mn44x09lDB8HVON/w7tcEacz/H4sbDIO0pBKHvjAAVWO6KeCL3mqV2VRZV5Dok
7skRIpfSEvOkCtNUCCVZTPeqI47Pid6Ywa9UG8rOIKA1Q+r09ijDrtwOVkSuKjmcjJ+3
QIsvDnR0zyUBgfvqWw/b95ci3WfhGmW4PADlk4Qx47easBOydH7HWvYZn0JOP3cAcZW7
502Q==
X-Gm-Message-State: AKwxytfQ9PNZZ68Tf20/gzhzDNr6Me8jM/UyoZTyjVlKdKcQrl5U+9NT
VHmTmGc0I/ZJd+csDAy8sT138KiJqopSbqEO/vc=
X-Google-Smtp-Source: AH8x226nDeSFDLpziV7+RQQUMxC1nju0YJ7GW4ReWeK2hSkbjm8GS9Rv/sPZ2436zNxFonROkzdutfKWNob++erheNg=
X-Received: by 10.31.0.136 with SMTP id 130mr4676416vka.15.1517262863691; Mon,
29 Jan 2018 13:54:23 -0800 (PST)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.78.155 with HTTP; Mon, 29 Jan 2018 13:54:23 -0800 (PST)
In-Reply-To: <CAE-z3OXX7Axf23oCDFmQYCth0tOQw9PEzLwvQO9Pk0wy7t1pYw@mail.gmail.com>
References: <CACRYg-4ho-XGK3xUdQW-ny2BFs2O91BuendrxuVYBni4wHrRqw@mail.gmail.com>
<CAE-z3OXX7Axf23oCDFmQYCth0tOQw9PEzLwvQO9Pk0wy7t1pYw@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Mon, 29 Jan 2018 21:54:23 +0000
X-Google-Sender-Auth: JbDPgZDajLj5fpN-2LzboUHOIac
Message-ID: <CAAS2fgRLMnpu5JHTxxJJvEQc8rj2Ox=cKCWcsvVdY06G0kKXJw@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>,
Bitcoin Protocol Discussion <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,DKIM_SIGNED,
DKIM_VALID, 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
Subject: Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?
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, 29 Jan 2018 21:54:25 -0000
On Mon, Jan 29, 2018 at 9:40 PM, Tier Nolan via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> For check locktime, the median of the last 11 blocks is used as an improved
> indicator of what the actual real time is. Again, it assumes that a
> majority of the miners are honest.
It would be more accurate to say that the median is not used for
improved accuracy but to mitigate a consensus incompatibility:
If the block's own timestamp were used for nlocktime and time based
nlocks were common on the network each miner would maximize their fee
income by setting the value as high as they could get away with. What
concerned us wasn't so much that this would make the times less
accurate (though it would) but rather that it would create an
incentive for a runaway situation that could harm network stability
(e.g. with all miners cranking times against the 2hr window, then
creating pressure for miners to accept further and further in the
future; each responding to his own local incentives).
This incentive incompatibility could have been addressed e.g. by using
the prior block's time, but since the protocol doesn't require times
to be monotone (and for good reason!) the simple implementation of
that wouldn't have been a soft-fork. The 11 block MTP worked out
nicely because the protocol already required new times to be larger
than that.
The timestamps in Bitcoin aren't intended to be particularly accurate.
They're used only for controlling the difficulty, and the adjustment
window is large enough that there isn't much distortion that can be
accomplished there. It's not clear to me that much better can really
be done... if there were tighter time requirements in the protocol
miners would address them by running NTP which as an _astounding_ lack
of security in terms of how it is commonly deployed. As far as I
know, I'm the only person whos ever mined blocks with their own
stratum 1 time source.
If times need to be accurate Bitcoin would need to use a rather
different design (e.g. each block would commit to the observation time
of the prior N blocks, and an iterative algorithm would solve for each
blocks time and each miners local offset).
IIRC open-timestamp calendar servers provide more precise
time-stamping under the assumption that the calendar server is
behaving correctly.
|
