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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
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 634D7E37
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 19:52:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com
[209.85.213.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93B6BFC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 19:52:20 +0000 (UTC)
Received: by mail-vk0-f53.google.com with SMTP id f2so32751034vkb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 11:52:20 -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=QAmugJCM/kfOmm0yw1x1I6F99BVGYnr4Z4DNktddWf4=;
b=Go2oZLb/aFVrXztL2SFu448YBrd7KrFWYxnVXERPsbjaijSIROMdTf67IAdmuzk1QX
8AD3f7Esv/RLsT1qcP0Bt7p7v4p0n7AGYZnLLTJPjBtynPhi+GYED7t3HTMyojrRGOtH
gziywLTfmV0i1qVlcBe1aShUBPjmr28JeoKM4OH/s205KjtfvzGVysCXSOCtryZQauQo
Xvp/F3mifBJt8fp+1XZs47uwPB3uHZxgRreYHDC034Z/fkG+WONrBXcIVu1KoMsfkNKK
jbwPBnc6p4z3oO01NXPHQh/rR5Yaa3rP0NjiPli6Rt/ZyzN5aBP1qNsNcPC+aeHk43l8
girg==
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=QAmugJCM/kfOmm0yw1x1I6F99BVGYnr4Z4DNktddWf4=;
b=ggGcSfDG9LBBlTvYemCrl62J68iXxThL8fYQetHXL45tUca1H1tjhX0Xcjn9jdmuhO
mYMt2gEND7Om8Fnilbbm2KYSUVqoJd1yGPJhHEZI+mxIyPAip9SHEdnGPfFIDWPc0iGF
8RxbVR+SW7TSRLFtMJisvYOy/P65mkaAsiZWFzoIwCes/GHLSzTu5ur0nWa2LyfxeYWp
Z9crLCpxfSBDX+nne6g/w/AzSyvriXTfsTQZV8Wj2CmQsYy6ynz5BXDeuUowWcLRS+op
JnToH89lCoziKQtPli9Bg2u0hpdHrkPTQIRCNJUuNrloZQ+FAtzpGfwzl39E0UuEoYz3
/cDQ==
X-Gm-Message-State: ALoCoQlqrA8RNsk+b6VaBMVIF5qb4ntv2F1BDmXu6YXcZp6E1fhYJE/vV8G3oSOsTd9HHsGWMJqYzKY7SVyxO1rIkNMusDfJIw==
MIME-Version: 1.0
X-Received: by 10.31.163.17 with SMTP id m17mr3526999vke.46.1450468339595;
Fri, 18 Dec 2015 11:52:19 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Fri, 18 Dec 2015 11:52:19 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Fri, 18 Dec 2015 11:52:19 -0800 (PST)
In-Reply-To: <CAFzgq-xNZmWrdwCDv3twdsqSWk-FyMuLYJjZ_bA42_5Po0mgEg@mail.gmail.com>
References: <CAFzgq-xNZmWrdwCDv3twdsqSWk-FyMuLYJjZ_bA42_5Po0mgEg@mail.gmail.com>
Date: Fri, 18 Dec 2015 20:52:19 +0100
Message-ID: <CABm2gDqJgPM1KRRSR3wSEhQ77Oq6P_VVvHwc3Yt4qnkAr7d2nA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Chun Wang <1240902@gmail.com>
Content-Type: multipart/alternative; boundary=001a11415d2423d0740527317a40
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 19:52:21 -0000
--001a11415d2423d0740527317a40
Content-Type: text/plain; charset=UTF-8
I agree that nHeight is the simplest option and is my preference.
Another option is to use the median time from the previous block (thus you
know whether or not the next block should start the miner confirmation or
not). In fact, if we're going to use bip9 for 95% miner upgrade
confirmation, it would be nice to always pick a difficulty retarget block
(ie block.nHeight % DifficultyAdjustmentInterval == 0).
Actually I would always have an initial height in bip9, for softforks too.
I would also use the sign bit as the "hardfork bit" that gets activated for
the next diff interval after 95% is reached and a hardfork becomes active
(that way even SPV nodes will notice when a softfork or hardfork happens
and also be able to tell which one is it).
I should update bip99 with all this. And if the 2 mb bump is
uncontroversial, maybe I can add that to the timewarp fix and th recovery
of the other 2 bits in block.nVersion (given that bip102 doesn't seem to
follow bip99's recommendations and doesn't want to give 6 full months as
the pre activation grace period).
On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> In many BIPs we have seen, include the latest BIP202, it is the block
> time that determine the max block size. From from pool's point of
> view, it cannot issue a job with a fixed ntime due to the existence of
> ntime roll. It is hard to issue a job with the max block size unknown.
> For developers, it is also easier to implement if max block size is a
> function of block height instead of time. Block height is also much
> more simple and elegant than time.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a11415d2423d0740527317a40
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I agree that nHeight is the simplest option and is my prefer=
ence.<br>
Another option is to use the median time from the previous block (thus you =
know whether or not the next block should start the miner confirmation or n=
ot). In fact, if we're going to use bip9=C2=A0 for 95% miner upgrade co=
nfirmation, it would be nice to always pick a difficulty retarget block (ie=
block.nHeight % DifficultyAdjustmentInterval =3D=3D 0).<br>
Actually I would always have an initial height in bip9, for softforks too.<=
br>
I would also use the sign bit as the "hardfork bit" that gets act=
ivated for the next diff interval after 95% is reached and a hardfork becom=
es active (that way even SPV nodes will notice when a softfork=C2=A0 or har=
dfork happens and also be able to tell which one is it).<br>
I should update bip99 with all this. And if the 2 mb bump is uncontroversia=
l, maybe I can add that to the timewarp fix and th recovery of the other 2 =
bits in block.nVersion (given that bip102 doesn't seem to follow bip99&=
#39;s recommendations and doesn't want to give 6 full months as the pre=
activation grace period).</p>
<div class=3D"gmail_quote">On Dec 18, 2015 8:17 PM, "Chun Wang via bit=
coin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attributio=
n"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">In many BIPs we have seen, include the la=
test BIP202, it is the block<br>
time that determine the max block size. From from pool's point of<br>
view, it cannot issue a job with a fixed ntime due to the existence of<br>
ntime roll. It is hard to issue a job with the max block size unknown.<br>
For developers, it is also easier to implement if max block size is a<br>
function of block height instead of time. Block height is also much<br>
more simple and elegant than time.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--001a11415d2423d0740527317a40--
|
