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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1YqRsX-0007NM-93
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 19:54:41 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.218.48 as permitted sender)
client-ip=209.85.218.48; envelope-from=jgarzik@bitpay.com;
helo=mail-oi0-f48.google.com;
Received: from mail-oi0-f48.google.com ([209.85.218.48])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqRsW-0006EC-0N
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 19:54:41 +0000
Received: by oign205 with SMTP id n205so42365796oig.2
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 12:54:34 -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:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=rfZ6jmNeLp0BwK9wizRD+mNEV8WWA2qxFGW21B+VYH4=;
b=MuGtbcbUiEOYDqSgcrnMeYy65jsTQJSPgZsPnb6xTsu8H7faApE3NTTcPx1GgSsVsR
1f0vj09Bf7pjlorY5GEzhUpdGI+VKcdvtlnxRGT1gYw+ulj/FhllrfE4gPxzDc86gco+
hpcgC0uMWTTBokC6+oQ7lLSon6ijs59+0e+IlTPxw8kn9ld5TP560kWeqVQkeIWbymCi
VbT/onCbe0jOFp8U+BKLBncLxzuK7nNdwAranqwEXqKapZJDWjuA8ZzuC4QrwUOjWnlW
ruRn3jlMC4kFFB4LTaNkc4D1plflRR98xLQDLdrCgtI49geOMhdY/tpIBtb5y3YCGVds
Rtuw==
X-Gm-Message-State: ALoCoQk+hCz8SI2OyOe74r0XvA3DUOnJNPufKkYC2wHfvo4GtN9/SmKhv8N29XpppkqQxTtIFmqt
X-Received: by 10.182.87.36 with SMTP id u4mr259224obz.50.1431028474566; Thu,
07 May 2015 12:54:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.108.149 with HTTP; Thu, 7 May 2015 12:54:13 -0700 (PDT)
In-Reply-To: <554BBDA2.7040508@gmail.com>
References: <554A91BE.6060105@bluematt.me>
<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
<554BA032.4040405@bluematt.me>
<CANEZrP3yM9wsSPNgpOsXDk-DjUy5PW2XuRTvK2AyCNbVJ5hZHw@mail.gmail.com>
<CADJgMzti7ROH90APiwg4NOAT5+Av=4i295b8VN0sbSLr4+WWRw@mail.gmail.com>
<CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
<554BBDA2.7040508@gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Thu, 7 May 2015 15:54:13 -0400
Message-ID: <CAJHLa0NcxOHkrtW2=-JgfsXQJkCO8Ym7icBwMx_2RsaWcPBnTw@mail.gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: multipart/alternative; boundary=089e013d0ddce3ec7905158347ca
X-Spam-Score: -0.7 (/)
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
-0.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YqRsW-0006EC-0N
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
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: Thu, 07 May 2015 19:54:41 -0000
--089e013d0ddce3ec7905158347ca
Content-Type: text/plain; charset=UTF-8
On Thu, May 7, 2015 at 3:31 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> (1) Blocks are essentially nearing "full" now. And by "full" he means
> that the reliability of the network (from the average user perspective) is
> about to be impacted in a very negative way
>
Er, to be economically precise, "full" just means fees are no longer zero.
Bitcoin behaves as it always has. It is no longer basically free to dump
spam into the blockchain, as it is today.
In the short term, blocks are bursty, with some on 1 minute intervals, some
with 60 minute intervals. This does not change with larger blocks.
> (2) Leveraging fee pressure at 1MB to solve the problem is actually really
> a bad idea. It's really bad while Bitcoin is still growing, and relying on
> fee pressure at 1 MB severely impacts attractiveness and adoption potential
> of Bitcoin (due to high fees and unreliability). But more importantly, it
> ignores the fact that for a 7 tps is pathetic for a global transaction
> system. It is a couple orders of magnitude too low for any meaningful
> commercial activity to occur. If we continue with a cap of 7 tps forever,
> Bitcoin *will* fail. Or at best, it will fail to be useful for the vast
> majority of the world (which probably leads to failure). We shouldn't be
> talking about fee pressure until we hit 700 tps, which is probably still
> too low.
>
[...]
1) Agree that 7 tps is too low
2) Where do you want to go? Should bitcoin scale up to handle all the
world's coffees?
This is hugely unrealistic. 700 tps is 100MB blocks, 14.4 GB/day -- just
for a single feed. If you include relaying to multiple nodes, plus serving
500 million SPV clients en grosse, who has the capacity to run such a
node? By the time we get to fee pressure, in your scenario, our network
node count is tiny and highly centralized.
3) In RE "fee pressure" -- Do you see the moral hazard to a software-run
system? It is an intentional, human decision to flood the market with
supply, thereby altering the economics, forcing fees to remain low in the
hopes of achieving adoption. I'm pro-bitcoin and obviously want to see
bitcoin adoption - but I don't want to sacrifice every decentralized
principle and become a central banker in order to get there.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--089e013d0ddce3ec7905158347ca
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">On T=
hu, May 7, 2015 at 3:31 PM, Alan Reiner <span dir=3D"ltr"><<a href=3D"ma=
ilto:etotheipi@gmail.com" target=3D"_blank">etotheipi@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
(1) Blocks are essentially nearing "full" now.=C2=A0 And by &=
quot;full" he
means that the reliability of the network (from the average user
perspective) is about to be impacted in a very negative way<br></div></=
blockquote><div><br></div><div>Er, to be economically precise, "full&q=
uot; just means fees are no longer zero.=C2=A0 Bitcoin behaves as it always=
has.=C2=A0 It is no longer basically free to dump spam into the blockchain=
, as it is today.<br><br>In the short term, blocks are bursty, with some on=
1 minute intervals, some with 60 minute intervals.=C2=A0 This does not cha=
nge with larger blocks.<br><br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
=20
(2) Leveraging fee pressure at 1MB to solve the problem is actually
really a bad idea.=C2=A0 It's really bad while Bitcoin is still gro=
wing,
and relying on fee pressure at 1 MB severely impacts attractiveness
and adoption potential of Bitcoin (due to high fees and
unreliability).=C2=A0 But more importantly, it ignores the fact that fo=
r
a 7 tps is pathetic for a global transaction system.=C2=A0 It is a coup=
le
orders of magnitude too low for any meaningful commercial activity
to occur.=C2=A0 If we continue with a cap of 7 tps forever, Bitcoin <b>=
will</b>
fail.=C2=A0 Or at best, it will fail to be useful for the vast majority
of the world (which probably leads to failure).=C2=A0 We shouldn't =
be
talking about fee pressure until we hit 700 tps, which is probably
still too low.=C2=A0 <br></div></blockquote><div>=C2=A0[...]<br><br></d=
iv><div>1) Agree that 7 tps is too low<br><br></div><div>2) Where do you wa=
nt to go?=C2=A0 Should bitcoin scale up to handle all the world's coffe=
es?=C2=A0 <br></div><div><br></div><div>This is hugely unrealistic.=C2=A0 7=
00 tps is 100MB blocks, 14.4 GB/day -- just for a single feed.=C2=A0 If you=
include relaying to multiple nodes, plus serving 500 million SPV clients e=
n grosse, who has the capacity to run such a node?=C2=A0 By the time we get=
to fee pressure, in your scenario, our network node count is tiny and high=
ly centralized.<br><br></div>3) In RE "fee pressure" -- Do you se=
e the moral hazard to a software-run system?=C2=A0 It is an intentional, hu=
man decision to flood the market with supply, thereby altering the economic=
s, forcing fees to remain low in the hopes of achieving adoption.=C2=A0 I&#=
39;m pro-bitcoin and obviously want to see bitcoin adoption - but I don'=
;t want to sacrifice every decentralized principle and become a central ban=
ker in order to get there.<br><div></div></div><br>-- <br><div class=3D"gma=
il_signature">Jeff Garzik<br>Bitcoin core developer and open source evangel=
ist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" tar=
get=3D"_blank">https://bitpay.com/</a></div>
</div></div>
--089e013d0ddce3ec7905158347ca--
|
