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
|
Return-Path: <marcel@jamin.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9428C259
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 06:38:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com
[209.85.160.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0367389
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 06:38:06 +0000 (UTC)
Received: by ykll84 with SMTP id l84so85720557ykl.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Aug 2015 23:38:06 -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:date:message-id:subject:from:to
:content-type;
bh=ch9VbC0igdusCJMziXoFbpBYrmR87vTPxbzHxLJQLpw=;
b=krqrnCpzex0NR2K5dgoozn0xe4weh1Jyr5gaHYOY+9NwZmSZyedvSO5VkYuMiRNUtE
7k7MZgCpUOlO5sS0hXrc/mX5dqiOnWxFdkLriK/dRq8hkT4PRaftTH/0BTOYpKhUy/+p
pktw4Jqw0B40b21XN1BEMx1RXR0ZIxgUZx9ilnFHllZQdun9MTaz+Din0m6ELIDgQptE
lSGicb9qTR6YDRFRKtRvZV8DNlEjnnlvNPqMcVPswiTCK3Zexn40znVAQ8gRFrp3WdPP
EBqQkhd5xPY14g3fSF3oe5KM8MkBCXjwUsTpyQxEHME798uonl3x2Slh1q4GO6VdE3V/
6/Fw==
X-Gm-Message-State: ALoCoQkgIVKs7YgFTJkiwr3OJS7Hm6KhA3fKEAeEfr1cPX7WvR5IE2RlAzFycqLw/iWMbSETfYmi
MIME-Version: 1.0
X-Received: by 10.129.83.136 with SMTP id h130mr5669985ywb.95.1439879885949;
Mon, 17 Aug 2015 23:38:05 -0700 (PDT)
Received: by 10.13.205.6 with HTTP; Mon, 17 Aug 2015 23:38:05 -0700 (PDT)
Date: Tue, 18 Aug 2015 08:38:05 +0200
Message-ID: <CAAUq486afiWsDzMhGsYmX3v5AsWmaHNq9taS-azUodg5cWWRKA@mail.gmail.com>
From: Marcel Jamin <marcel@jamin.net>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114d6f181f3cab051d902997
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
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
Subject: [bitcoin-dev] Simplifying the blocksize limit debate
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: Tue, 18 Aug 2015 06:38:07 -0000
--001a114d6f181f3cab051d902997
Content-Type: text/plain; charset=UTF-8
I'm going to list a few assumtions / observations / understandings around
this debate. Please point out the incorrect ones.
* Most developers here agree that 1 MB is not a magic constant and that the
limit has to increase eventually.
* Most developers want to reduce the amount of policy decisions
bitcoin-core makes as much as possible.
* The most conservative option for the 4 billion dollar system that is
bitcoin is to keep the limit.
* Technological growth in bandwidth, cpu and storage exists and relative to
that growth, the blocksize limit is effectively decreased. Keeping the
limit as it is today, or was five years ago, means we need to adjust for
technological growth.
* Doing so will not reduce current decentralization, however measured.
* Increasing the blocksize limit will always require a hard-fork.
Decreasing, or stopping the growth of the blocksize limit will always be
possible via soft-fork.
* Problems arising from underestimating the need for a larger blocksize
limit are increasingly harder to fix. Problems arising from a limit that is
getting too high are more easy to fix.
* This means we can be optimistic when estimating future technological
growth.
--001a114d6f181f3cab051d902997
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I'm going to list a few assumtions / observations=
/ understandings around this debate. Please point out the incorrect ones.<=
br></div><div><br></div><div>* Most developers here agree that 1 MB is not =
a magic constant and that the limit has to increase eventually.</div><div><=
br></div><div>* Most developers want to reduce the amount of policy decisio=
ns bitcoin-core makes as much as possible.</div><div><br></div><div>* The m=
ost conservative option for the 4 billion dollar system that is bitcoin is =
to keep the limit.</div><div><br></div><div>* Technological growth in bandw=
idth, cpu and storage exists and relative to that growth, the blocksize lim=
it is effectively decreased. Keeping the limit as it is today, or was five =
years ago, means we need to adjust for technological growth.</div><div><br>=
</div><div>* Doing so will not reduce current decentralization, however mea=
sured.</div><div><br></div><div>* Increasing the blocksize limit will alway=
s require a hard-fork. Decreasing, or stopping the growth of the blocksize =
limit will always be possible via soft-fork.</div><div><br></div><div>* Pro=
blems arising from underestimating the need for a larger blocksize limit ar=
e increasingly harder to fix. Problems arising from a limit that is getting=
too high are more easy to fix.</div><div><br></div><div><div>* This means =
we can be optimistic when estimating future technological growth.</div><div=
><br></div></div></div>
--001a114d6f181f3cab051d902997--
|
