summaryrefslogtreecommitdiff
path: root/d4/b725a16ef5e3ab2393983757edd0ec0d9808af
blob: b7a451412c135de1d2af27421da60945bc69ee36 (plain)
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
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 615F371F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 18:10:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com
	[209.85.212.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1879516A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 18:10:24 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so5114830wib.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 11:10:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=UxqRuImyl4n6xb8YspdOMXkUQ6xTiaG2QD6dC/G3E9Y=;
	b=SzwPGLrIdHU8BYrf6iPlMU2O6IuixvJdbeOFY7d5eHsbojo4/MkFx9x6J1X7LsOGMe
	0jp0pQyOiX3CaWDX8f2I+DNqze1HH2O3N1cKmj/1MXLCnVBssagnGyYtO12jWAnKhiPr
	wecmblk42WDgZokpvt+vAiXG4T4oi7j7VEsFfE6zSNHRteR3Mzcj0ASJmVhME8ugCdKO
	mLAEyNDZSSx47HoFHX7/yesISA4gxBu2PBJzmvj54FOJtgCXISz3C5MChL5pClqBLdEG
	Tmta9tuXLpSEtD35fJWoEgbnmaz5i5lq3V7tqrBh/xOko3obZzUh0GVNe35TuQrdgUAs
	Zm6A==
MIME-Version: 1.0
X-Received: by 10.180.86.129 with SMTP id p1mr53815114wiz.71.1437675022916;
	Thu, 23 Jul 2015 11:10:22 -0700 (PDT)
Received: by 10.27.171.138 with HTTP; Thu, 23 Jul 2015 11:10:22 -0700 (PDT)
In-Reply-To: <C5A70F53-4779-457A-A06A-686877706F89@gmail.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
	<CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
	<CAPWm=eW8RgrG1CMEAMN4GeiMjZecFvNtZB_Y4rZNeofWSD0=Wg@mail.gmail.com>
	<CADm_WcYCUHs9Qe_T6WJOCUSK6stXYD8v6z5JcGHfRMURoOSFTA@mail.gmail.com>
	<CABm2gDq3JyZx0QCRDbcNSLSOBKdpi4h_7VN1XL8N42U38+eBAA@mail.gmail.com>
	<55B113AF.40500@thinlink.com>
	<CABsx9T1MTc-GmuQyFN1vaFK=CDWV_L214Pi9nR6jLMouQQD0fw@mail.gmail.com>
	<C5A70F53-4779-457A-A06A-686877706F89@gmail.com>
Date: Thu, 23 Jul 2015 14:10:22 -0400
Message-ID: <CADL_X_exckh5T2BfzPEp26fPR3TD69QarwroDEdS_9wtnKbf+g@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=f46d044286300b226a051b8ecd9c
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
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: Thu, 23 Jul 2015 18:10:25 -0000

--f46d044286300b226a051b8ecd9c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't bee=
n
> optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning
> disks),
> what if the network is attacked?  (attacked HOW???), current p2p network
> is using
> the simplest, stupidest possible block propagation algorithm...)"
>
> ... to "lets work together and work through the problems and scale it up.=
"
>
>
> Let=E2=80=99s be absolutely clear about one thing - block size increases =
are *not*
> about scaling the network. Can we please stop promoting this falsehood? I=
t
> doesn=E2=80=99t matter by what number we multiply the block size=E2=80=A6=
we can NEVER
> satisfy the full demand if we insist on every single transaction from eve=
ry
> single person everywhere in the world being on the blockchain=E2=80=A6it=
=E2=80=99s just
> absurd.
>
>
Increasing block size only temporarily addresses one significant issue -
> how to postpone having to deal with transaction fees, which by design, ar=
e
> how the cost of operating the Bitcoin network (which is already very
> expensive) is supposed to be paid for ultimately. Suggesting we avoid
> dealing with this constitutes a new economic policy - dealing with it is
> the default economic policy we=E2=80=99ve all known about from the beginn=
ing=E2=80=A6so
> please stop claiming otherwise.
>
>
Larger block sizes don't scale the network, they merely increase how much
load we allow the network to bear. On the flip side, the scalability
proposals will still require larger blocks if we are ever to support
anything close to resembling "mainstream" usage. This is not an either/or
proposition - we clearly need both.

- Jameson

> On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Why not help on a project that actually seems to offer great scalability
> like the lightning network? There have been great progress there.
>
>
> Exactly. There=E2=80=99s been tremendous progress here in addressing scal=
ability,
> yet I don=E2=80=99t see you participating in that discussion, Gavin.
>
> On Jul 23, 2015, at 5:17 AM, Jorge Tim=C3=B3n via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But it seems to me that the "not now side" has no centralization
> concerns at all and their true position is "not ever hit the blocksize
> limit", that's the only explanation I can find to their lack of
> answers to the "when do you think we should allow users to notice that
> there's a limit in the blocksize to guarantee that the system can be
> decentralized?".
>
>
> I agree with what you=E2=80=99re saying, Jorge=E2=80=A6but It=E2=80=99s e=
ven worse than that. The
> July 4th fork illustrated that the security model of the network itself
> could be at risk from the increasing costs in validation causing people t=
o
> rely on others to validate for them=E2=80=A6and increasing block size onl=
y makes
> the problem worse.
>
> - Eric Lombrozo
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--f46d044286300b226a051b8ecd9c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev <span di=
r=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><span =
class=3D""><br><div><blockquote type=3D"cite"><div>On Jul 23, 2015, at 9:28=
 AM, Gavin Andresen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a>&gt; wrote:</div><br><div><div style=3D"font-family:Helvetica;font-si=
ze:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spa=
cing:normal;line-height:normal;text-align:start;text-indent:0px;text-transf=
orm:none;white-space:normal;word-spacing:0px">I&#39;d really like to move f=
rom &quot;IMPOSSIBLE because... =C2=A0(electrum hasn&#39;t been optimized</=
div><div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;fo=
nt-variant:normal;font-weight:normal;letter-spacing:normal;line-height:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px">(by the way: you should run on SSDs, LevelDB isn&#39;t de=
signed for spinning disks),</div><div style=3D"font-family:Helvetica;font-s=
ize:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-sp=
acing:normal;line-height:normal;text-align:start;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px">what if the network is attac=
ked? =C2=A0(attacked HOW???), current p2p network is using</div><div style=
=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant:nor=
mal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:=
start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px">the simplest, stupidest possible block propagation algorithm...)&quot;<=
/div><div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;f=
ont-variant:normal;font-weight:normal;letter-spacing:normal;line-height:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px"><br></div><div style=3D"font-family:Helvetica;font-size:=
12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacin=
g:normal;line-height:normal;text-align:start;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px">... to &quot;lets work together =
and work through the problems and scale it up.&quot;</div></div></blockquot=
e></div><br></span><div>Let=E2=80=99s be absolutely clear about one thing -=
 block size increases are *not* about scaling the network. Can we please st=
op promoting this falsehood? It doesn=E2=80=99t matter by what number we mu=
ltiply the block size=E2=80=A6we can NEVER satisfy the full demand if we in=
sist on every single transaction from every single person everywhere in the=
 world being on the blockchain=E2=80=A6it=E2=80=99s just absurd.</div><div>=
=C2=A0<br></div></div></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div sty=
le=3D"word-wrap:break-word"><div></div><div>Increasing block size only temp=
orarily addresses one significant issue - how to postpone having to deal wi=
th transaction fees, which by design, are how the cost of operating the Bit=
coin network (which is already very expensive) is supposed to be paid for u=
ltimately. Suggesting we avoid dealing with this constitutes a new economic=
 policy - dealing with it is the default economic policy we=E2=80=99ve all =
known about from the beginning=E2=80=A6so please stop claiming otherwise.</=
div><span class=3D""><div><br></div></span></div></blockquote><div><br></di=
v><div>Larger block sizes don&#39;t scale the network, they merely increase=
 how much load we allow the network to bear. On the flip side, the scalabil=
ity proposals will still require larger blocks if we are ever to support an=
ything close to resembling &quot;mainstream&quot; usage. This is not an eit=
her/or proposition - we clearly need both.</div><div><br></div><div>- James=
on=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-=
word"><span class=3D""><div></div><div><div></div><blockquote type=3D"cite"=
><div>On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br><div><span style=3D=
"font-family:Verdana;float:none;display:inline!important">Why not help on a=
 project that actually seems to offer great scalability like the lightning =
network? There have been great progress there.</span></div></blockquote></d=
iv><div><span style=3D"font-family:Verdana;float:none;display:inline!import=
ant"><br></span></div></span><div><font face=3D"Verdana">Exactly. There=E2=
=80=99s been tremendous progress here in addressing scalability, yet I don=
=E2=80=99t see you participating in that discussion, Gavin.</font></div><sp=
an class=3D""><div><font face=3D"Verdana"><br></font></div><blockquote type=
=3D"cite"><div><div>On Jul 23, 2015, at 5:17 AM, Jorge Tim=C3=B3n via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br><=
div><span style=3D"float:none;display:inline!important">But it seems to me =
that the &quot;not now side&quot; has no centralization</span><br><span sty=
le=3D"float:none;display:inline!important">concerns at all and their true p=
osition is &quot;not ever hit the blocksize</span><br><span style=3D"float:=
none;display:inline!important">limit&quot;, that&#39;s the only explanation=
 I can find to their lack of</span><br><span style=3D"float:none;display:in=
line!important">answers to the &quot;when do you think we should allow user=
s to notice that</span><br><span style=3D"float:none;display:inline!importa=
nt">there&#39;s a limit in the blocksize to guarantee that the system can b=
e</span><br><span style=3D"float:none;display:inline!important">decentraliz=
ed?&quot;.</span></div></div></blockquote><div><span style=3D"float:none;di=
splay:inline!important"><br></span></div></span><div><span style=3D"float:n=
one;display:inline!important">I agree with what you=E2=80=99re saying, Jorg=
e=E2=80=A6but It=E2=80=99s even worse than that. The July 4th fork illustra=
ted that the security model of the network itself could be at risk from the=
 increasing costs in validation causing people to rely on others to validat=
e for them=E2=80=A6and increasing block size only makes the problem worse.<=
/span></div><div><span style=3D"float:none;display:inline!important"><br></=
span></div><div><span style=3D"float:none;display:inline!important">- Eric =
Lombrozo</span></div></div><br>____________________________________________=
___<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></div>

--f46d044286300b226a051b8ecd9c--