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
|
Return-Path: <achow101@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C547192B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Feb 2017 23:52:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f195.google.com (mail-qt0-f195.google.com
[209.85.216.195])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C3E117A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Feb 2017 23:52:58 +0000 (UTC)
Received: by mail-qt0-f195.google.com with SMTP id h53so12868492qth.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Feb 2017 15:52:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding;
bh=A3czNtoRC51w/Eh4xyx1NM2rYp7pbmTeaKy6G3ID9Ak=;
b=Ua1FTcPtOgUKKCDF6kAjrQ9dbYt/JUNQtzxjLVhvxWPKfRi+o2e/RK+Bg2kPxkepAc
SiRbFSXE5F7UQJCPJ81gA6syjfjZIkozaBu6/cV2oOiWz3+zlJxCX884Xe6gxC0piaim
6Uqm8eLO2pNhz9s3byN53U9XmeTD3yp0EYp0225DcPTkDnsNXDjA/O/1D+u42SgDPuDU
8zcW2zcvR9Nl9T8xQmqDwvxtPyEZeaWsYWjCG77NrBS14WqLB25aL1Kltxepn9vtnniA
Ijq5MWsOQ52FsaJfzA2ZDMp9dcZVI+ZVaT+z0cpADZ2vsB8l8uihfz8id0qoOnUkcq9z
rL0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding;
bh=A3czNtoRC51w/Eh4xyx1NM2rYp7pbmTeaKy6G3ID9Ak=;
b=HEWfyxsZzAM6+GzO+Fm8YLh3ywTwblc8fC+AYjq1Cmuux/VroMu1A2kFSd022Q+8PF
bahemA43WF5P2HBRatxge8t3zfxybhBsSwWYYD5VwsAy66t3L8yKleUbkgj8JdoNhMTw
1iXJjLeEEueKWNsBNt0SPPYqE4qNCXlSdzRpGOXs1aiK6wICM78UT2zyoshNYjOq7dx9
hGGq1qiir/MMPceA+fCOTY3I0IZK6mIxnWG/WhPXabeQMfbuFhiecDem6sswTQH12F+D
Id2eDraNkaYq8TNP4uxj1KiOZ6qpc3qNo1uLlHuJLkHcA+hMtaZRIg3BwJXr6bBVhRFI
X6WA==
X-Gm-Message-State: AMke39m8F3D72H84ElFXD8x900awnZa8zcJ5i3udOkc7HxkapRWAi0KKF7gPOcDnf2aGrw==
X-Received: by 10.200.51.6 with SMTP id t6mr6609232qta.75.1486338777374;
Sun, 05 Feb 2017 15:52:57 -0800 (PST)
Received: from [192.168.1.6] ([129.2.206.150])
by smtp.gmail.com with ESMTPSA id
b190sm31562615qkg.32.2017.02.05.15.52.56
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 05 Feb 2017 15:52:56 -0800 (PST)
To: Luke Dashjr <luke@dashjr.org>, bitcoin-dev@lists.linuxfoundation.org
References: <ea63ed5a-4280-c063-4984-5bc8a4b2aafa@gmail.com>
<201702052302.29599.luke@dashjr.org>
From: Andrew C <achow101@gmail.com>
Message-ID: <03b80a7b-6c8c-cdff-1826-6535bef12993@gmail.com>
Date: Sun, 5 Feb 2017 18:53:03 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <201702052302.29599.luke@dashjr.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Sun, 05 Feb 2017 23:52:58 -0000
On 2/5/2017 6:02 PM, Luke Dashjr wrote:
> My BIP draft didn't make progress because the community opposes any blo=
ck size=20
> increase hardfork ever.
=46rom what I have observed, it seems to be that people are more so
opposed to a hard fork when there is a comparable soft fork available
than simply opposed to any block size increase hard fork ever. From the
various threads discussing your proposal, it seemed that many would
favor it if it increased over 1 MB sooner or if it never even decreased
in the first place.
> Your version doesn't address the current block size=20
> issues (ie, the blocks being too large).=20
Many users are of the opposite opinion, that the block size is too
small. I understand that the decrease is to allow the blockchain size to
grow more slowly thereby allowing users to be more likely to run full
nodes. Unfortunately, I think that we are way past the point of no
return on that. The blockchain is already 100+ GB. Decreasing the block
size is not going to make that any smaller and is not going to make it
any less painful to run a full node. Given that in order to start up a
new full node will still require downloading at least 100 GB of data, I
don't think that decreasing the block size will better facilitate full
node creation. Furthermore, the current trend with ISPs (at least in the
US) is implementing data and bandwidth caps so users are still unlikely
to start up new full nodes regardless of any changes that we can
currently do.
> So you've retained the only certain-
> DOA parts of my proposal, and removed the most useful part... I'm not s=
ure the=20
> point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no=
sense=20
> to keep the BIP 9 deployment at all - either it gets consensus or it do=
esn't,=20
> but miners have no part in deployment of it.
Yes, I know deployment needs to be fixed. I was more proposing this for
comment on the modified block size schedule. I just kept the deployment
as it was originally. However, we could use a modified version of BIP 9
by using one of the top three bits and a longer locked-in period as a
grace period for all users to upgrade.
>
> On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:=
>> Hello all,
>>
>> Many people have expressed discontent with Luke-jr's proposed block si=
ze
>> BIP, in particular with the decrease in size that would occur if it we=
re
>> to be activated prior to 2024.
>>
>> I have decided to modify the proposal to instead begin the increase
>> steps at the current 1000000 byte limit. The increases and the time sp=
am
>> of each increase will remain the same, just that the increase begins
>> from 1000000 bytes instead of 300000 bytes.
>>
>> Furthermore, instead of a fixed schedule from a fixed point in time, t=
he
>> increases will instead be calculated off of the MTP of the activation
>> block (the first block to be in the active state for this fork).
>>
>> While this proposal shares many of the same issues with the one it
>> modifies, I hope that it will be slightly less controversial and can
>> allow us to move forward with scaling Bitcoin.
>>
>> The full text of the proposal can be found at
>> https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawik=
i.
>> My implementation of it is available at
>> https://github.com/achow101/bitcoin/tree/bip-blksize
>>
>>
>> Andrew
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
