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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
|
Return-Path: <kalle@rosenbaum.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5E45A273
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 20:27:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com
[209.85.220.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 421A7A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 20:27:20 +0000 (UTC)
Received: by qkhu186 with SMTP id u186so106816206qkh.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 13:27:19 -0700 (PDT)
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=sTQOVI9IMZ/W2hPYgJ348zwxqpnzq77yXil0JuFwS5Q=;
b=GwsAAhDoNCVF0p3d9z8Ik+VO3pS4thWQagU/eh5M3iMPOOs2oGrdmvH9JZDYY9Wor2
HB7jZXBgyCL97YU4lmgxrSt5EvArSLyHmLFHhfaZtONECJdQs90Ls5wQ4Wi9SV5B3EE1
LFLuGWurcLgx9Z08OfOOiSZlzKgEdr31STwHiU73e4XHzv+t78aanAZTPO3ZgUQ1PLVh
tbwZEOwS36Tgx4MX8zKh1YrVjQhiwyYyinfukD0XHihxwRZDRYa/yoroz9R3xb0imoJ6
+DjUw7cm20XvilsTjEHNq8cbYh/tjfgE9VWB5Uy2UPCWsC8hSuX3a5PRcQRyEREBWnnJ
6xLA==
X-Gm-Message-State: ALoCoQlkOz/pb/5IvaWyPg2jO7pj8ZfC4+6Pt0A2NLPH1jo5gQrsBuHBV9rWpyeJ0sTXS7JZdqqf
MIME-Version: 1.0
X-Received: by 10.55.18.31 with SMTP id c31mr46064357qkh.15.1435004839474;
Mon, 22 Jun 2015 13:27:19 -0700 (PDT)
Received: by 10.96.127.227 with HTTP; Mon, 22 Jun 2015 13:27:19 -0700 (PDT)
In-Reply-To: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
Date: Mon, 22 Jun 2015 22:27:19 +0200
Message-ID: <CAPswA9wVEs6oH8CxafLvLy78bpC937HZccjXHwyq8JVMV7qiQA@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
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:27:21 -0000
Thank you!
A few questions/comments:
* In the specification, you refer to "t_start". I guess you mean "time_start"?
* Miners can, especially when close to a block doubling or shortly
after activation, to some extent manipulate max block size by
manipulating the time stamp in the block header within valid limits.
According to the pseudo code in the specification, the first and a
handful of subsequent blocks after activation could actually have
negative max block sizes due to this (depending on how you define the
% operator of the pseudo code). I haven't checked the reference
implementation, but I do think that the specification section should
explicitly handle this.
Regards,
Kalle
2015-06-22 20:18 GMT+02:00 Gavin Andresen <gavinandresen@gmail.com>:
> I promised to write a BIP after I'd implemented
> increase-the-maximum-block-size code, so here it is. It also lives at:
> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
>
> I don't expect any proposal to please everybody; there are unavoidable
> tradeoffs to increasing the maximum block size. I prioritize implementation
> simplicity -- it is hard to write consensus-critical code, so simpler is
> better.
>
>
>
>
> BIP: ??
> Title: Increase Maximum Block Size
> Author: Gavin Andresen <gavinandresen@gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2015-06-22
>
> ==Abstract==
>
> This BIP proposes replacing the fixed one megabyte maximum block size with a
> maximum size that grows over time at a predictable rate.
>
> ==Motivation==
>
> Transaction volume on the Bitcoin network has been growing, and will soon
> reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte
> maximum block size. Increasing the maximum size reduces the impact of that
> limit on Bitcoin adoption and growth.
>
> ==Specification==
>
> After deployment on the network (see the Deployment section for details),
> the maximum allowed size of a block on the main network shall be calculated
> based on the timestamp in the block header.
>
> The 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 doublings will
> increase linearly based on the block's timestamp. The maximum size of blocks
> after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
>
> Expressed in pseudo-code, using integer math:
>
> function max_block_size(block_timestamp):
>
> time_start = 1452470400
> time_double = 60*60*24*365*2
> size_start = 8000000
> if block_timestamp >= time_start+time_double*10
> return size_start * 2^10
>
> // Piecewise-linear-between-doublings growth:
> time_delta = block_timestamp - t_start
> doublings = time_delta / time_double
> remainder = time_delta % time_double
> interpolate = (size_start * 2^doublings * remainder) / time_double
> max_size = size_start * 2^doublings + interpolate
>
> return max_size
>
> ==Deployment==
>
> Deployment shall be controlled by hash-power supermajority vote (similar to
> the technique used in BIP34), but the earliest possible activation time is
> 2016-01-11 00:00:00 UTC.
>
> Activation is achieved when 750 of 1,000 consecutive blocks in the best
> chain have a version number with bits 3 and 14 set (0x20000004 in hex). The
> activation time will be the timestamp of the 750'th block plus a two week
> (1,209,600 second) grace period to give any remaining miners or services
> time to upgrade to support larger blocks. If a supermajority is achieved
> more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will
> be 2016-01-11 00:00:00 UTC.
>
> Block version numbers are used only for activation; once activation is
> achieved, the maximum block size shall be as described in the specification
> section, regardless of the version number of the block.
>
>
> ==Rationale==
>
> The initial size of 8,000,000 bytes was chosen after testing the current
> reference implementation code with larger block sizes and receiving feedback
> from miners stuck behind bandwidth-constrained networks (in particular,
> Chinese miners behind the Great Firewall of China).
>
> The doubling interval was chosen based on long-term growth trends for CPU
> power, storage, and Internet bandwidth. The 20-year limit was chosen because
> exponential growth cannot continue forever.
>
> Calculations are based on timestamps and not blockchain height because a
> timestamp is part of every block's header. This allows implementations to
> know a block's maximum size after they have downloaded it's header, but
> before downloading any transactions.
>
> The deployment plan is taken from Jeff Garzik's proposed BIP100 block size
> increase, and is designed to give miners, merchants, and
> full-node-running-end-users sufficient time to upgrade to software that
> supports bigger blocks. A 75% supermajority was chosen so that one large
> mining pool does not have effective veto power over a blocksize increase.
> The version number scheme is designed to be compatible with Pieter's
> Wuille's proposed "Version bits" BIP.
>
> TODO: summarize objections/arguments from
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
>
> TODO: describe other proposals and their advantages/disadvantages over this
> proposal.
>
>
> ==Compatibility==
>
> This is a hard-forking change to the Bitcoin protocol; anybody running code
> that fully validates blocks must upgrade before the activation time or they
> will risk rejecting a chain containing larger-than-one-megabyte blocks.
>
> Simplified Payment Verification software is not affected, unless it makes
> assumptions about the maximum depth of a transaction's merkle branch based
> on the minimum size of a transaction and the maximum block size.
>
> ==Implementation==
>
> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
