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
|
Return-Path: <mickeybob@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BB326A04
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 14:39:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
[209.85.212.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2C5E221C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 14:39:53 +0000 (UTC)
Received: by wicgi11 with SMTP id gi11so39062625wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 07:39:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=pmyUkPZ/jIr8rfgc1LRSctT0dVZtJw/J3ptt5BTH2Cw=;
b=u1LoXVyE9zroMGfGsabY4r0QmokYYje4RuZKcNDaAAWnnL2bo/2pU28aKTC0k42NDM
kmwwpOISe4DHUBvAqcrrqn+ESouGbLcIbxrPQVlPtLRBBaW8X0aOGKOUzc9/J0N0gZ8N
9eG8jZeddwtOE5per72//dwmZ954v9xRZ/YugE6AYp3lRqGya2IaelRz5ZtPTXBZg8DU
oRvPzY6QYFOaQktyOwytfQ94Hqa6k4dyfzMKeh34WRk2rm3xR+7/mnjQjSuhS1lmrLjx
gIGAzYkZloKsgAWDEYWb2udZ4lAvNXgKD8WLAiJkyUxaLPWgGRh4LNRHCdPTGRvtG2tj
/C4Q==
MIME-Version: 1.0
X-Received: by 10.180.95.35 with SMTP id dh3mr6446521wib.30.1435415991561;
Sat, 27 Jun 2015 07:39:51 -0700 (PDT)
Received: by 10.27.10.1 with HTTP; Sat, 27 Jun 2015 07:39:51 -0700 (PDT)
Date: Sat, 27 Jun 2015 10:39:51 -0400
Message-ID: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
From: Michael Naber <mickeybob@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=f46d04447e1d48340b051980d40c
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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] A Proposed Compromise to the Block Size Limit
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: Sat, 27 Jun 2015 14:39:53 -0000
--f46d04447e1d48340b051980d40c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Demand to participate in a low-fee global consensus network will likely
continue to rise. Technology already exists to meet that rising demand
using a blockchain with sufficient block size. Whether that blockchain is
Bitcoin Core with an increased block size, or whether it is a fork, market
forces make it almost certain that demand will be met by a blockchain with
adequate capacity. These forces ensure that not only today=E2=80=99s block =
size
will be increased, but also that future increases will occur should the
demand arise.
In order to survive, Bitcoin Core must remain the lowest-fee,
highest-capacity, most secure, distributed, fastest, overall best solution
possible to the global consensus problem. Attempting to artificially
constrain the block size below the limits of technology for any reason is a
conflict with this objective and a threat to the survival of Bitcoin Core.
At the same time, scheduling large future increases or permitting unlimited
dynamic scaling of the block size limit raises concerns over availability
of future computing resources. Instead, we should manually increase the
block size limit as demand occurs, except in the special case that
increasing the limit would cause an undue burden upon users wishing to
validate the integrity of the blockchain.
Compromise: Can we agree that raising the block size to a static 8MB now
with a plan to increase it further should demand necessitate except in the
special case above is a reasonable path forward?
--f46d04447e1d48340b051980d40c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Demand to participate in a low-fee global consensus n=
etwork will likely continue to rise. Technology already exists to meet that=
rising demand using a blockchain with sufficient block size. Whether that =
blockchain is Bitcoin Core with an increased block size, or whether it is a=
fork, market forces make it almost certain that demand will be met by a bl=
ockchain with adequate capacity. These forces ensure that not only today=E2=
=80=99s block size will be increased, but also that future increases will o=
ccur should the demand arise.=C2=A0</div><div><br></div><div>In order to su=
rvive, Bitcoin Core must remain the lowest-fee, highest-capacity, most secu=
re, distributed, fastest, overall best solution possible to the global cons=
ensus problem. Attempting to artificially constrain the block size below th=
e limits of technology for any reason is a conflict with this objective and=
a threat to the survival of Bitcoin Core. At the same time, scheduling lar=
ge future increases or permitting unlimited dynamic scaling of the block si=
ze limit raises concerns over availability of future computing resources. I=
nstead, we should manually increase the block size limit as demand occurs, =
except in the special case that increasing the limit would cause an undue b=
urden upon users wishing to validate the integrity of the blockchain.=C2=A0=
</div><div><br></div><div>Compromise: Can we agree that raising the block s=
ize to a static 8MB now with a plan to increase it further should demand ne=
cessitate except in the special case above is a reasonable path forward?</d=
iv></div>
--f46d04447e1d48340b051980d40c--
|
