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
|
Return-Path: <piverson1024@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CDB34A88
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 19:56:50 +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 7EB05196
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 19:56:50 +0000 (UTC)
Received: by mail-vk0-f53.google.com with SMTP id d188so101170093vka.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 12:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=kqJxr+Vl2fPEmryt0RpEFsa//IPSMPzdPnfNP9kaImM=;
b=UFqJlMFT8LVSeDWqXu/bkDFPJTCoSmVkNV1ZyfqtsLyDUTXG1PQzBuQRmLt/I27QoB
vJoPaBp3PijmDOIDjyCibQfVJYb2WnLDyavyZNzrtzXPwFoQEhGSrnLqmafZjtCkYa1H
W7KNUeXVUn4Co55FD42v+DNT4IYvnE2XkGRfxwiSPi3KhPrUVhsCNx1tv1DGi6EWodx5
EQpR8PWFaIiay6FdbJSqmH0XWtdHvi6LTqWDK7aadgZcgCpCvpkdyrMyK2Y7XO4QVwWI
e6vZEqktMg28xTFTD6DSyMJp+WOyrxtZNQL3RzjyliS6I6pTGuuaLJu3naaK0F6++Q+z
a1sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=kqJxr+Vl2fPEmryt0RpEFsa//IPSMPzdPnfNP9kaImM=;
b=njF+vNVUbm9bfbwinl/v7GQVv2wMFpo7epiSd0WlZQA6FrcXR2EeSXgtCgq4/Poj2y
MhVaHl6ahjV0YFFe/PP+lsMbGBR2mLA1N+aqghlbB7NgThm4ahMRNJYiD66KwqKV1uHk
hBLlMz1mygqP1EJ6FAUR1iAxXaVDPhaXYbk+lAfrsEVqU0JITwdacq+eVHmCxA2X6fZ1
7z4YGJt8C0Dk+bQMvVS5bPNClwQBpYuvgL+qFDWpmIVEcllxC1rWHnYEbGSWuAbrNtIt
hzKGrTE8n6N/CTbnJ/QZaVZ6IemF2tZCVjkQSbipAL+v8mWME83krHSN7UDzo8mxLlUZ
uC7g==
X-Gm-Message-State: AFeK/H2qGFQ0mtRFlI8AdiExJQm7hRxUponund/od4AHvMMI+eBsj4kzeBEs88GnP2rWrrYs3OHzONmKoimIHQ==
X-Received: by 10.176.88.194 with SMTP id r2mr8527252uac.139.1490731009404;
Tue, 28 Mar 2017 12:56:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.254.15 with HTTP; Tue, 28 Mar 2017 12:56:49 -0700 (PDT)
From: Paul Iverson <piverson1024@gmail.com>
Date: Tue, 28 Mar 2017 12:56:49 -0700
Message-ID: <CAAeo5+jSfp5XWj=EYJ_i-XS+=RjxfY-co7+b7iu3Gd=WWHbHzQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=f403045f8a86457589054bcfdc9a
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 28 Mar 2017 20:00:08 +0000
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
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: Tue, 28 Mar 2017 19:56:50 -0000
--f403045f8a86457589054bcfdc9a
Content-Type: text/plain; charset=UTF-8
Thank you for the proposal Wang Chung!
It is clear that, spam aside, blocks are getting full and we need increase
them soon. What I don't like about your proposal is it forces all node
operators to implicitly accept larger blocks in 2020, even maybe against
their will. 32 MB blocks might result in a loss of decentralization, and it
might be too difficult to coordinate for small blocks before it's too late.
So I think Core can't decide on hard forks like this. It must be left up to
the users. I think only choice is for Core to add a run-time option to
allow node operators to increase block size limit, so that this very
controversial decision is not coming from Core. It must come from the
community.
--f403045f8a86457589054bcfdc9a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thank you for the proposal Wang Chung! =C2=A0<div><br></di=
v><div>It is clear that, spam aside, blocks are getting full and we need in=
crease them soon. What I don't like about your proposal is it forces al=
l node operators to implicitly accept larger blocks in 2020, even maybe aga=
inst their will. 32 MB blocks might result in a loss of decentralization, a=
nd it might be too difficult to coordinate for small blocks before it's=
too late. =C2=A0</div><div><br></div><div>So I think Core can't decide=
on hard forks like this. It must be left up to the users. I think only cho=
ice is for Core to add a run-time option to allow node operators to increas=
e block size limit, so that this very controversial decision is not coming =
from Core. It must come from the community. =C2=A0</div><div><br></div></di=
v>
--f403045f8a86457589054bcfdc9a--
|
