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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YzRin-0004Ug-Bk
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 15:33:49 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.170 as permitted sender)
client-ip=209.85.212.170; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f170.google.com;
Received: from mail-wi0-f170.google.com ([209.85.212.170])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzRim-00071I-AI
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 15:33:49 +0000
Received: by wicmx19 with SMTP id mx19so74747061wic.0
for <bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 08:33:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.157.168 with SMTP id wn8mr41359456wjb.79.1433172822312;
Mon, 01 Jun 2015 08:33:42 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.143.9 with HTTP; Mon, 1 Jun 2015 08:33:41 -0700 (PDT)
In-Reply-To: <CAFzgq-wzQaS5K1hQMz_TcbvKMKQbAde488bx4uDXhODNXpqtsA@mail.gmail.com>
References: <554BE0E1.5030001@bluematt.me>
<CAFzgq-xByQ1E_33_m3UpXQFUkGc78HKnA=7XXMshANDuTkNsvA@mail.gmail.com>
<CABsx9T0kbRe31LMwk499MQUw225f5GGd67GfhXBezHmDqxkioA@mail.gmail.com>
<CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
<CAFzgq-zTybEQyGz0nq90u5n5JZcJzxQS_XKaTpr5POJi-tHM6A@mail.gmail.com>
<CABsx9T2L5bi-c63-KqSifOMeNayUWSPo0_Hx8VjMR_4=kC3ixg@mail.gmail.com>
<CAE28kUT61qYxqV0mOqw5Dan=eMiCvnG2SnsAeWzOWTxwLydyeQ@mail.gmail.com>
<CABsx9T2hfpts5y_M6PdDcxmq9Q2smesJ0Nmp9a9iyPD_MoPC9g@mail.gmail.com>
<CAE28kUTZV3YsaSCX2d5YwLetnf=f+bOWGrwxLXdZFywTZ=+Pjg@mail.gmail.com>
<CALC81CNq-GK5q6R4bmgHL5_Ej2+cZrtQMMLVmuhvMxkZokM3hQ@mail.gmail.com>
<CAE28kUQr+kUPak67tcNQGGscUXtJiD1LiXfjdD8_LMUWyVdR5w@mail.gmail.com>
<CANEZrP12WAcUOJp5UYg4pfWL7_4WiAHWWZAoaxAb5xB+qAP4Xg@mail.gmail.com>
<CAFzgq-ykeMeWF-ndgSm9upHTe8j6ZFYhBQjFs_WSz1oVd29j7g@mail.gmail.com>
<CAFzgq-x+-s_Nbt4z-C4SWQbHdPr159AmL2JvpP0zg1axM+Vwcw@mail.gmail.com>
<CABsx9T2aEvPs68pQA-KrtaDQFcTTtiB36eqKAcJRkiOFQr6WsA@mail.gmail.com>
<CAFzgq-wzQaS5K1hQMz_TcbvKMKQbAde488bx4uDXhODNXpqtsA@mail.gmail.com>
Date: Mon, 1 Jun 2015 17:33:41 +0200
X-Google-Sender-Auth: zbR6ZOy4lHiBmFzagG9kNqTNRsw
Message-ID: <CANEZrP1OX4j=AoiHDQx10mSVY6D4Yu7rd9Lnq=RW-H+byhCnyw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Chun Wang <1240902@gmail.com>
Content-Type: multipart/alternative; boundary=089e0122e968f9ce9b0517768c4a
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YzRim-00071I-AI
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 15:33:49 -0000
--089e0122e968f9ce9b0517768c4a
Content-Type: text/plain; charset=UTF-8
I'm OK with a smaller size + a formula that ramps it up over time. We are
far from having enough demand to fill 10MB blocks, let alone 20MB today.
To put it in perspective, to be feeling squeezed inside 10MB within two
years, we would need to double usage five times. I wish I knew a way to
make that happen. So the chances of us going to 20MB blocks full of real
transactions any time soon is close to zero short of some amazing killer
app that takes the world by storm (in which case: yay, nice problem to
have). As long as capacity significantly outpaces organic growth, we should
avoid problems.
The reason to pick 20MB then is merely one of expedience: we have to pick a
number, 20 is tested and seems to work, and we don't want to get caught by
surprise if demand does outstrip expectations.
Still, I question the underlying logic. We have no idea what connectivity
into China will look like a few years from now: it's seems to be a function
of politics rather than hardware trends. It might go down rather than up.
So 10 vs 20 feels a bit arbitrary. We can't let the Chinese government
dictate how Bitcoin is used, that would never be accepted by the rest of
the world. But if we optimistically assume things don't get worse, and 10
== more acceptance, then alright - it should make no difference in practice.
--089e0122e968f9ce9b0517768c4a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm OK with a smaller size + a formula that ramps it u=
p over time. We are far=C2=A0from having enough demand to fill 10MB blocks,=
let alone 20MB today.<div><br></div><div>To put it in perspective, to be f=
eeling squeezed inside 10MB within two years, we would need to double usage=
five times. I wish I knew a way to make that happen. So the chances of us =
going to 20MB blocks full of real transactions any time soon is close to ze=
ro short of some amazing killer app that takes the world by storm (in which=
case: yay, nice problem to have). As long as capacity significantly outpac=
es organic growth, we should avoid problems.</div><div><br></div><div>The r=
eason to pick 20MB then is merely one of expedience: we have to pick a numb=
er, 20 is tested and seems to work, and we don't want to get caught by =
surprise if demand does outstrip expectations.</div><div><div><br></div><di=
v><div>Still, I question the underlying logic. We have no idea what connect=
ivity into China will look like a few years from now: it's seems to be =
a function of politics rather than hardware trends. It might go down rather=
than up. So 10 vs 20 feels a bit arbitrary. We can't let the Chinese g=
overnment dictate how Bitcoin is used, that would never be accepted by the =
rest of the world. But if we optimistically assume things don't get wor=
se, and 10 =3D=3D more acceptance, then alright - it should make no differe=
nce in practice.</div></div></div><div><br></div></div>
--089e0122e968f9ce9b0517768c4a--
|
