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
|
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5A62519B5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2015 20:43:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com
[209.85.213.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C6B117F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2015 20:43:33 +0000 (UTC)
Received: by igbkq10 with SMTP id kq10so38770755igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2015 13:43:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=vinumeris.com; s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=KFYsMC1jq1v42d5xxrcXJ6J7RstDUoGVy92V/JSsu/w=;
b=o8yuUJl5zcWM1n0+URcJdsxVI+aVoHYnEa7uIvPGufivL79GQZakGpJa5Qi3XSTihA
RS9mT8sUj16Mf7R7+S7UzG6rjMfs8ZL8sqvN1lVWFbhxBn/rKuBD40vQf//duNjTOakn
oGBz9XB9UGel7JjZFnNtCxPnJ6aRP9KN4ouso=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=KFYsMC1jq1v42d5xxrcXJ6J7RstDUoGVy92V/JSsu/w=;
b=d/NoPet6gI4vPAZcP5pfg2WHpKm1SZiNw3yW51FyK9rh7bDb8n8NxAR5eWwsK/VaoO
kLewhpnC8LG4MooPz7Zy8JfvTRlx1L2NVObdS5T6qnd/aAKKXPlWWKLF0DdITYxBMlbj
y/fhz+sRYy47FPtaWqL8QozK2izrAz7EuiAPoCGYgEZEKVxz/ruQr7WV7YqWdWFTGSrt
ZXFkQf5pNDAOfPAwscap6KFx0zrSSxzKCeTCGESp0RD0SBBEXQC9Eud4gYNxfxHSfkZQ
+3hIUwZQEU//la0GYrexLg4UCqeqXbqpxIWvFeZyR6vsffthJJTbvHPgcTVBxqardT0y
sbgQ==
X-Gm-Message-State: ALoCoQm8APVUvqaGhxmAPQN+FSBS+dFMCaT6yCKgBxDzt0qGNcQ5/s1uAH8Cs1pZihsNekOTJZuN
MIME-Version: 1.0
X-Received: by 10.50.17.4 with SMTP id k4mr4629052igd.34.1442695412980; Sat,
19 Sep 2015 13:43:32 -0700 (PDT)
Received: by 10.50.192.233 with HTTP; Sat, 19 Sep 2015 13:43:32 -0700 (PDT)
In-Reply-To: <trinity-83bd9372-08bc-4c3e-812f-206ed3322913-1442678624612@3capp-mailcom-bs16>
References: <CADm_WcaLKqhR=WcJ5B52Q9SAAa+AdZY6Kz5OCQVUc_RQm6e9gg@mail.gmail.com>
<55F9E47D.50507@mattcorallo.com>
<CAOG=w-t2ZYQbx8+mG5FX8vzgAC_tb8A6KMABmudHQbrquEqX-Q@mail.gmail.com>
<55FC6EBF.9090504@mattcorallo.com>
<CA+w+GKSK42DjSKqpWj9=s=catGox-n5+AWjh=Mg5=nRpxsf4HQ@mail.gmail.com>
<trinity-83bd9372-08bc-4c3e-812f-206ed3322913-1442678624612@3capp-mailcom-bs16>
Date: Sat, 19 Sep 2015 21:43:32 +0100
Message-ID: <CA+w+GKRYVbck1rfAAVcxkG8FwoSK93ZSjL0xTBd87J1Xs1Dmuw@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: cipher anthem <cipher.anthem@gmx.com>
Content-Type: multipart/alternative; boundary=089e011767bf9c42cd05201fb3ac
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
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, 19 Sep 2015 20:43:34 -0000
--089e011767bf9c42cd05201fb3ac
Content-Type: text/plain; charset=UTF-8
>
> Let me get this straight. You start this whole debate with a "kick the can
> down the road" proposal to increase the block size to 20MB, which obviously
> would require another hard fork in the future, but if someone else proposes
> a similar "kicka the can" proposal you will outright reject it?
>
Which part of "in the next few years" was unclear?
This seems to be a persistent problem in the block size debates: the
assumption that there are only two numbers, zero and infinity.
BIP101 tops out at 8 gigabyte blocks, which would represent extremely high
transaction rates compared to today. *If* Bitcoin ever became so popular,
it would be a long way in the future, and many things could have happened:
1. Bitcoin may have become as irrelevant as the Commodore 64 is.
2. We may have invented upgrades that make Bitcoin 100x more efficient
than today.
3. Hardware may have improved so much that it no longer matters.
4. The world may have been devastated by nuclear war and nobody gives a
shit about internet currencies anymore, because there is no internet.
It's silly to ignore the time dimension in these decisions. Bitcoin will
not last forever: even if it becomes very successful it will one day it
will be replaced by something better, so it does not have to handle
infinite usage.
But hey, as you bring it up, I'd have been happy with no upper limit at
all. There's nothing magic about 8 gigabytes. I go along with BIP 101
because it is still the only proposal that is both reasonable and
implemented, and I'm willing to compromise.
--089e011767bf9c42cd05201fb3ac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div><div style=3D"font-family:Verdana;font-size=
:12.0px"><div><div>Let me get this straight. You start this whole debate wi=
th a "kick the can down the road" proposal to increase the block =
size to 20MB, which obviously would require another hard fork in the future=
, but if someone else proposes a similar "kicka the can" proposal=
you will outright reject it?</div></div></div></div></blockquote><div><br>=
</div><div>Which part of "in the next few years" was unclear?</di=
v><div><br></div><div>This seems to be a persistent problem in the block si=
ze debates: the assumption that there are only two numbers, zero and infini=
ty.</div><div><br></div><div>BIP101 tops out at 8 gigabyte blocks, which wo=
uld represent extremely high transaction rates compared to today. <b>If</b>=
=C2=A0Bitcoin ever became so popular, it would be a long way in the future,=
and many things could have happened:</div><div><ol><li>Bitcoin may have be=
come as irrelevant as the Commodore 64 is.</li><li>We may have invented upg=
rades that make Bitcoin 100x more efficient than today.</li><li>Hardware ma=
y have improved so much that it no longer matters.</li><li>The world may ha=
ve been devastated by nuclear war and nobody gives a shit about internet cu=
rrencies anymore, because there is no internet.</li></ol><div>It's sill=
y to ignore the time dimension in these decisions. Bitcoin will not last fo=
rever: even if it becomes very successful it will one day it will be replac=
ed by something better, so it does not have to handle infinite usage.</div>=
</div><div><br></div><div>But hey, as you bring it up, I'd have been ha=
ppy with no upper limit at all. There's nothing magic about 8 gigabytes=
. I go along with BIP 101 because it is still the only proposal that is bot=
h reasonable and implemented, and I'm willing to compromise.</div></div=
></div></div>
--089e011767bf9c42cd05201fb3ac--
|
