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
|
Return-Path: <jeanpaulkogelman@me.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 31F82273
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 20:32:27 +0000 (UTC)
X-Greylist: delayed 01:00:01 by SQLgrey-1.7.6
Received: from st11p02im-asmtp001.me.com (st11p02im-asmtp001.me.com
[17.172.220.113])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10916A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 20:32:26 +0000 (UTC)
Received: from st11p02im-spool001.me.com ([17.172.220.115])
by st11p02im-asmtp001.me.com
(Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31
2015)) with ESMTP id <0NQD00PJ929YCN70@st11p02im-asmtp001.me.com> for
bitcoin-dev@lists.linuxfoundation.org;
Mon, 22 Jun 2015 19:32:23 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.14.151,1.0.33,0.0.0000
definitions=2015-06-22_04:2015-06-22, 2015-06-22,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
adjust=0
reason=mlx scancount=1 engine=7.0.1-1412110000
definitions=main-1506220328
MIME-version: 1.0
Content-type: multipart/alternative;
boundary="Boundary_(ID_8x5MvtbAqGGKg2SFMMv0lw)"
Received: from localhost ([17.172.220.223]) by st11p02im-spool001.mac.com
(Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31
2015))
with ESMTP id <0NQD00WZU29YD070@st11p02im-spool001.mac.com>; Mon,
22 Jun 2015 19:32:22 +0000 (GMT)
To: Gavin Andresen <gavinandresen@gmail.com>
From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
Date: Mon, 22 Jun 2015 19:32:22 +0000 (GMT)
X-Mailer: iCloud MailClient15CPlus63 MailServer15C.19370
X-Originating-IP: [159.153.138.99]
Message-id: <dd09d1e5-57fb-46ef-8bc0-0fdccf9e7abb@me.com>
X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,HTML_MESSAGE,
MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD 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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev]
=?utf-8?q?Draft_BIP_=3A_fixed-schedule_block_size_i?=
=?utf-8?q?ncrease?=
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: Mon, 22 Jun 2015 20:32:27 -0000
--Boundary_(ID_8x5MvtbAqGGKg2SFMMv0lw)
Content-type: text/plain; charset=utf-8; format=flowed
Content-transfer-encoding: quoted-printable
=0A=0AOn Jun 22, 2015, at 11:18 AM, Gavin Andresen <gavinandresen@gmail.co=
m> wrote:=0A=0AThe maximum size shall be 8,000,000 bytes at a timestamp of=
2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63=
,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:=
00 UTC (timestamp 2083190400). The maximum size of blocks in between doubl=
ings will increase linearly based on the block's timestamp. The maximum si=
ze of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.=0A=
=C2=A0=0ASince it's possible that block timestamps aren't chronological in=
order, what would happen if a block following a size increase trigger is =
back in the past before the size increase? Would that block have a lower s=
ize restriction again? Would using block height not be a more stable numbe=
r to work with?=0A=0Ajp=
--Boundary_(ID_8x5MvtbAqGGKg2SFMMv0lw)
Content-type: multipart/related;
boundary="Boundary_(ID_Q5j7gjd7Zgy+cPAiPTmiyA)"; type="text/html"
--Boundary_(ID_Q5j7gjd7Zgy+cPAiPTmiyA)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable
<html><body><div><br></div><div><br>On Jun 22, 2015, at 11:18 AM, Gavin Andresen <g=
avinandresen@gmail.com> wrote:<br></div><div><blockquote type=3D"cite">=
<div class=3D"msg-quote"><div dir=3D"ltr"><div><div class=3D"gmail_extra">=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The maximu=
m size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC =
(timestamp 1452470400), and shall double every 63,072,000 seconds (two yea=
rs, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190=
400). The maximum size of blocks in between doublings will increase linear=
ly based on the block's timestamp. The maximum size of blocks after 2036-0=
1-06 00:00:00 UTC shall be 8,192,000,000 bytes.</div><div class=3D"gmail_e=
xtra"></div></div></div></div></div></blockquote><span> </span></div>=
<div><span>Since it's possible that block timestamps aren't chronological =
in order, what would happen if a block following a size increase trigger i=
s back in the past before the size increase? Would that block have a lower=
size restriction again? Would using block height not be a more stable num=
ber to work with?</span></div><div><span><br></span></div><div><span>jp</s=
pan></div></body></html>=
--Boundary_(ID_Q5j7gjd7Zgy+cPAiPTmiyA)--
--Boundary_(ID_8x5MvtbAqGGKg2SFMMv0lw)--
|
