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
|
Return-Path: <bram@bittorrent.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 15BC17A9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Jul 2017 03:39:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5F3771DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Jul 2017 03:39:11 +0000 (UTC)
Received: by mail-wm0-f45.google.com with SMTP id w126so209603728wme.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 04 Jul 2017 20:39:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bittorrent-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:cc;
bh=65Yt9s32d4LOpjxU4aHCT8QwZ5rezmoA1vrIFHrRrns=;
b=yPT9tWM8DLRkv51MTbFS7ckbM8P4wB0jJuUkn5+mHE7Ox7QhonDn2IPk5sYNmPpMrK
5aMRr5rJZeKEgG9ADoD5dAG9Wc9f1Uq30LbqNUYPLluU2vwjKt2T3vdOKnK7JUKGuzQa
DffKKxCOL8iudH5P5vLNE10RzHs2Uh9s0eyCVIXFaF5QQYMzHQDV/msUieclEM29ZZ2w
PsK7GttImorR1YHasQgC/Gy2BRMrZgk8SvvYS1CsLZQpp+DUmuNgTuzR169U97hyJtvO
SJ3Aar3ojk+xfyVNrBtxoWmVw+qlf8yuAWwR48VTMHmA5mgYKsAIU/SdOsfY/EOMHEJJ
pO7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:cc;
bh=65Yt9s32d4LOpjxU4aHCT8QwZ5rezmoA1vrIFHrRrns=;
b=F7N94WAFmhMVMUV7bY5tekJybBDYUKXDRNtTmGSBz2JSr7AJ0FDMvTt0WDOFA3WTQw
C0T96O7xNDh0IFeGQmrnDrmeBHqk1A1GKMUFS772ni1GdAT6U/EqTLkLodlQ+zzgjwnE
uPaU3QwY7re7VWHva3ptw9+kMNEX/KX26nIDEqJYvax40V7tRY0iLI7SfF962YUhZ8S+
BZpiAoYaXNGDvZsmANbJeGBjc/JCQ4rxHhd1weMeFDLOiP7m045OoOjmtKxVVZ+Y5zGI
Z/B2joZCXdgXoA8Fv8Z3+psjmjdIBVB0cCYBs+8j/tukJJj+QPTd8Z0miplUDBTZNnmF
jAwA==
X-Gm-Message-State: AIVw112gvtIvP9NdMhXeESZNHKfT81kNaQ/YNXjYS/O3Or5saNaUCNl2
AfySWmOf2FDRV6mZ/RmZuwrDRtMGgCeK
X-Received: by 10.28.7.211 with SMTP id 202mr15265878wmh.113.1499225949824;
Tue, 04 Jul 2017 20:39:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.181.152 with HTTP; Tue, 4 Jul 2017 20:39:09 -0700 (PDT)
In-Reply-To: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
References: <KXL-Ie0q1dKTlbQ2XCyTRCzoQLND-Q7M9CFvYTfhjgeiZ4K3knpetQSwwLviO6whuHXQnFPg-rg8q1xW8w5mNnYFxalvx5_9Vci63lC9ju4=@protonmail.ch>
From: Bram Cohen <bram@bittorrent.com>
Date: Tue, 4 Jul 2017 20:39:09 -0700
Message-ID: <CA+KqGkqMtHzxzKObn7OkXsdrP4sKOFm-z1bJWThhPe4jXFmzDw@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114435122d7d96055389beec"
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, MISSING_HEADERS,
RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
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: Wed, 05 Jul 2017 03:39:12 -0000
--001a114435122d7d96055389beec
Content-Type: text/plain; charset="UTF-8"
On Tue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable
> to miners fiddling with timestamps in a way that could prevent or delay
> activation - for example by only advancing the block timestamp by 1 second
> you would never meet the threshold (although this would come a the penalty
> of hiking the difficulty dramatically).
>
> On the other hand, the exact date of a height based thresholds is hard to
> predict a long time in advance due to difficulty fluctuations. However,
> there is certainty at a given block height and it's easy to monitor.
>
You could get most of the best of both with a combination of the two: Have
the activation be a timestamp plus a certain number of blocks to come after
maybe about 100, which is more than enough to make sure all the games which
can be played with timestamps have passed but a small enough amount that it
doesn't add much uncertainty to wall clock time.
--001a114435122d7d96055389beec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div>Some people have criticized BIP9's blocktime =
based thresholds arguing they are confusing (the first retarget after thres=
hold). It is also vulnerable to miners fiddling with timestamps in a way th=
at could prevent or delay activation - for example by only advancing the bl=
ock timestamp by 1 second you would never meet the threshold (although this=
would come a the penalty of hiking the difficulty dramatically).<br></div>=
<div><br></div><div>On the other hand, the exact date of a height based thr=
esholds is hard to predict a long time in advance due to difficulty fluctua=
tions. However, there is certainty at a given block height and it's eas=
y to monitor.<br></div></blockquote><div><br></div><div>You could get most =
of the best of both with a combination of the two: Have the activation be a=
timestamp plus a certain number of blocks to come after maybe about 100, w=
hich is more than enough to make sure all the games which can be played wit=
h timestamps have passed but a small enough amount that it doesn't add =
much uncertainty to wall clock time.</div><div><br></div></div></div></div>
--001a114435122d7d96055389beec--
|
