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
|
Return-Path: <1240902@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D106C937
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Nov 2015 02:56:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com
[209.85.213.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B8551AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Nov 2015 02:56:56 +0000 (UTC)
Received: by igcph11 with SMTP id ph11so7443777igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 Nov 2015 18:56:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=Iq3dgNOecCUaftfAdhinQi/fTqzc81GFJzdUWZ5ak8o=;
b=iZ5kQBUiWn/QlXWsBh23ZvQhYHZ6Z/E8mAlk0MXbGFemJHLZODJqeB2Wtg8V74gKf1
V/sa2FwgwZ8lCrq9EpVV2Naizkr6A/51eTpU7kD+0rB7g+Z24wqteoYM/+K5RUyRd7zy
ErjXjHx5kCjNtOKfJBgNOl3PUg7kCFyS2C0Bw+hNdPk1W0PwkyvxCdtBXIC+D0PjHTVo
a6U8gF1ekSNowNtbo88ZtMZ8x967re6rHLKA02luO0O8bEKH5mMII1BVgfdFAL7daikq
dR273zr9yxWa3zOmkr524iMowvJegWk8eza7Ut33UJIXiSjJfZE5j3d7WSg6Ibs+bond
H/zg==
MIME-Version: 1.0
X-Received: by 10.50.59.227 with SMTP id c3mr794949igr.58.1447383415754; Thu,
12 Nov 2015 18:56:55 -0800 (PST)
Received: by 10.107.4.138 with HTTP; Thu, 12 Nov 2015 18:56:55 -0800 (PST)
In-Reply-To: <CAEkt4Xu6vBFtRVEnXCWJa0f9OYi9wLKwToxc3p+KPfMuV5y0GA@mail.gmail.com>
References: <CAEkt4Xu6vBFtRVEnXCWJa0f9OYi9wLKwToxc3p+KPfMuV5y0GA@mail.gmail.com>
Date: Fri, 13 Nov 2015 10:56:55 +0800
Message-ID: <CAFzgq-xmXcEKN0_0e8de0UDOJEXuivbz986-dsSC5BCYLA2t1A@mail.gmail.com>
From: Chun Wang <1240902@gmail.com>
To: John Sacco <johnsock@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
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] BIP - Block size doubles at each reward halving
with max block size of 32M
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, 13 Nov 2015 02:56:57 -0000
How about these specs:
* 1 MB, height < 210000;
* 2 MB, 210000 <= height < 420000;
* 4 MB, 420000 <= height < 630000;
* 8 MB, 630000 <= height < 840000;
* 16 MB, 840000 <= height < 1050000;
* 32 MB, height >= 1050000.
On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Devs,
>
>
> Please consider the draft proposal below for peer review.
>
>
> Thanks,
>
>
> John
>
>
> BIP
>
> BIP: ?
>
> Title: Block size doubles at each reward halving with max block size of
> 32M
>
> Author: John Sacco <johnsock@gmail.com>
>
> Status: Draft
>
> Type: Standards Track
>
> Created: 2015-11-11
>
> Abstract
>
> Change max block size to 2MB at next block subsidy halving, and double the
> block size at each subsidy halving until reaching 32MB.
>
> Copyright
>
> This proposal belongs in the public domain. Anyone can use this text for any
> purpose with proper attribution to the author.
>
> Motivation
>
> 1. Gradually restores block size to the default 32 MB setting originally
> implemented by Satoshi.
>
> 2. Initial increase to 2MB at block halving in July 2016 would have
> minimal impact to existing nodes running on most hardware and networks.
>
> 3. Long term solution that does not make enthusiastic assumptions
> regarding future bandwidth and storage availability estimates.
>
> 4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by year
> 2031.
>
> 5. Exercise network upgrade procedure during subsidy reward halving, a
> milestone event with the goal of increasing awareness among miners and node
> operators.
>
> Specification
>
> 1. Increase the maximum block size to 2MB when block 630,000 is reached
> and 75% of the last 1,000 blocks have signaled support.
>
> 2. Increase maximum block size to 4MB at block 840,000.
>
> 3. Increase maximum block size to 8MB at block 1,050,000.
>
> 4. Increase maximum block size to 16MB at block 1,260,000.
>
> 5. Increase maximum block size to 32MB at block 1,470,000.
>
> Backward compatibility
>
> All older clients are not compatible with this change. The first block
> larger than 1M will create a network partition excluding not-upgraded
> network nodes and miners.
>
> Rationale
>
> While more comprehensive solutions are developed, an increase to the block
> size is needed to continue network growth. A longer term solution is needed
> to prevent complications associated with additional hard forks. It should
> also increase at a gradual rate that retains and allows a large distribution
> of full nodes. Scheduling this hard fork to occur no earlier than the
> subsidy halving in 2016 has the goal of simplifying the communication
> outreach needed to achieve consensus, while also providing a buffer of time
> to make necessary preparations.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
