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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 790A4EAE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 22:58:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com
[209.85.213.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC2AF169
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 22:58:30 +0000 (UTC)
Received: by mail-vk0-f54.google.com with SMTP id j66so73731758vkg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 14:58:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=qjVL0LKkK9BNR69YGuw1AkkPaCzHvfmQBctJGm2TkH4=;
b=M8hdm6b6sKtnHgPmnsu/AcYLU+AalGWUyg+ItXSCEteIOSfp20/h+KhgDySXLr+WDD
oEw1n4UGVCcM7P1Xwn2APe1SvX6Biq+GiKcrVqZ3nvEPIGf5I2nOdBntD1HZjbf046ch
9Df8KZxoEYuoCXyrTsYbGKCtMqOgTQbRk0wZPb2ojujO5xIryR/f+NXf3FotAgk1IRMJ
N0TAAxXzR+t7O9PT/ybyuXNUSOQhd718uZ6Fijdb3B/ycO0yd5rNKT/fOhsFSKHLXFnx
UConJq2FOqYfHFVRB3SWs5C6xpny6SGnZJJrLq4tDQN27DHEk2JCSpEHBm7HCWAm65eN
6XtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=qjVL0LKkK9BNR69YGuw1AkkPaCzHvfmQBctJGm2TkH4=;
b=F3jNcRFOkbExGIKDTOr6yadqAMBWDAIFewsh1Dk+HrsSATXxo5yt0jHNNp5gJPEh/r
liH5A7tOE9zldQfSsMqGs9/nNVmVLhLKWziYsFhH0DgerB2mcHJiSwl1Lim8N2uLJ0ba
L1cm4W0Uf4fFf8NlRxf1Za0l+Pkzl8d2nfULBw+g/xdKf4iyzHpx1a1vcZ7/D28jvWzl
xYoq+vglolk7nqbSdcEfkOfAwnsh6S0Z2pt/k0IcHIpPejo/KquMBvKx+J14TSI98wne
waJl5zCrrsdGRqbXdJXxGCo9pNsETTlf+mjq4khZCXWLP1BrD0Ca1o3Me5Du/TEOriY6
Geew==
X-Gm-Message-State: ALoCoQm0r9gHC1Bipn0SM4T88wVA4UPKpPVtZ2LquGcRbDtypfD1LTuRW5eWvIjWj8XDXW0IcO3Ba23mMJzYjHvLa4iwCepXJA==
MIME-Version: 1.0
X-Received: by 10.31.165.16 with SMTP id o16mr3685720vke.80.1450479510181;
Fri, 18 Dec 2015 14:58:30 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Fri, 18 Dec 2015 14:58:29 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Fri, 18 Dec 2015 14:58:29 -0800 (PST)
In-Reply-To: <99EC10C0-CA98-4AA9-B94E-FB6775BAF55B@petertodd.org>
References: <CAFzgq-xNZmWrdwCDv3twdsqSWk-FyMuLYJjZ_bA42_5Po0mgEg@mail.gmail.com>
<CABm2gDqJgPM1KRRSR3wSEhQ77Oq6P_VVvHwc3Yt4qnkAr7d2nA@mail.gmail.com>
<99EC10C0-CA98-4AA9-B94E-FB6775BAF55B@petertodd.org>
Date: Fri, 18 Dec 2015 23:58:29 +0100
Message-ID: <CABm2gDraEJVA3+dLYLEvMYNfDCkuZj+eajLcPsMKXBwnEP+KCw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11414ff2f56ffa05273413ca
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] The increase of max block size should be
determined by block height instead of block time
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 18 Dec 2015 22:58:31 -0000
--001a11414ff2f56ffa05273413ca
Content-Type: text/plain; charset=UTF-8
On Dec 18, 2015 9:43 PM, "Peter Todd" <pete@petertodd.org> wrote:
> FWIW all these median time based schemes should be using median time
past: the point is to use a time that the block creator has no direct
control of, while still tying the rule to wall clock time for planning
purposes.
Well, if after the "planned clock time" you need to wait for the next diff
retarget and then wait for 95% (bip9) I think the value of being able to
use "human friendly clock time" is very dubious (specially since median
time is different from real-world time anyway).
But yeah, not giving the creator of the current block direct control over
whether its block starts the activation process or not is achieved with
median time of the previous block just as well as nHeight does.
So even if I disagree with the value that median time brings over the
simpler height approach, let's please decide on one and always use that for
both hardforks and softforks as part of bip9 (which we would need to
modify).
An initial time threshold is not necessary for uncontroversial softforks,
but it doesn't hurt (you can always set it in the past if you want to not
use it) and in fact it simplifies bip9's implementation.
Let's please decide once and for all, update bip9 and bip99 and stop doing
something different on every hardfork patch we write.
--001a11414ff2f56ffa05273413ca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Dec 18, 2015 9:43 PM, "Peter Todd" <<a href=3D"mailto:pete@=
petertodd.org">pete@petertodd.org</a>> wrote:<br>
> FWIW all these median time based schemes should be using median time p=
ast: the point is to use a time that the block creator has no direct contro=
l of, while still tying the rule to wall clock time for planning purposes.<=
/p>
<p dir=3D"ltr">Well, if after the "planned clock time" you need t=
o wait for the next diff retarget and then wait for 95% (bip9) I think the =
value of being able to use "human friendly clock time" is very du=
bious (specially since median time is different from real-world time anyway=
).<br>
But yeah, not giving the creator of the current block direct control over w=
hether its block starts the activation process or not is achieved with medi=
an time of the previous block just as well as nHeight does.<br>
So even if I disagree with the value that median time brings over the simpl=
er height approach, let's please decide on one and always use that for =
both hardforks and softforks as part of bip9 (which we would need to modify=
).<br>
An initial time threshold is not necessary for uncontroversial softforks, b=
ut it doesn't hurt (you can always set it in the past if you want to no=
t use it) and in fact it simplifies bip9's implementation.<br>
Let's please decide once and for all, update bip9 and bip99 and stop do=
ing something different on every hardfork patch we write.</p>
--001a11414ff2f56ffa05273413ca--
|
