summaryrefslogtreecommitdiff
path: root/eb/97b002023e4b2d4806f7701aee47de43271cce
blob: 4755fc0a5e0a86591b6db52696ae8c144f7b387c (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
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jgarzik@bitpay.com>) id 1YqNQo-0001QI-OV
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 15:09:46 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.214.177 as permitted sender)
	client-ip=209.85.214.177; envelope-from=jgarzik@bitpay.com;
	helo=mail-ob0-f177.google.com; 
Received: from mail-ob0-f177.google.com ([209.85.214.177])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YqNQm-0004sq-9D
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 15:09:46 +0000
Received: by obfe9 with SMTP id e9so33659377obf.1
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 07 May 2015 08:09:38 -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=FpIQmLBozQhDqTZkHT2kdgRhlq2lueqXNm8cthiRhR0=;
	b=RoBNvR51k6LZlmejWyTJueCbkpUNycbPb6anGoufWbNrou1YiDzXzRSbb0lD9+iDf1
	/GsioIarDqE80wChXsYIFlCfvypJbjjHzFPBal1bUJdngOG0km+gNYlsPeYcyXQ1PCtG
	2hueu68JvkfAYySwdTBhouALXbU7HXEQx51Lrtpj2p1zMGVRHFtGFI3NKPHpKrNU5q+m
	ZxVFx5WEOftkhCNoLP1CJe1MVIjRlTfDARsLlbbuxpjM7om9IzcSH2J7AofuH0m5iKE6
	aXMAKwzXI2lfJKlOJjbpfIQhJayihYrQt3XpS8Jhq4+nMxo73FPeKqxPI8BcK74ymwYO
	bakQ==
X-Gm-Message-State: ALoCoQnmzEM9hY7ORtaOx6sqzWvOoOLGkRMUbmqgcQ7+yi+joog9R0qK3Ov8T8FXLq69OE+klEvH
X-Received: by 10.60.92.131 with SMTP id cm3mr3552151oeb.23.1431011378881;
	Thu, 07 May 2015 08:09:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.108.149 with HTTP; Thu, 7 May 2015 08:09:18 -0700 (PDT)
In-Reply-To: <CAPWm=eUFe7dKJCLeNACZ4n9vw0Xj9rHVM_RRLSczGXNU-ShR2w@mail.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>
	<CAPWm=eUFe7dKJCLeNACZ4n9vw0Xj9rHVM_RRLSczGXNU-ShR2w@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Thu, 7 May 2015 11:09:18 -0400
Message-ID: <CAJHLa0MB8Hh-7np8EpFMj0jioNpxH_D-C=KZrt_Ri6p_Bovc5w@mail.gmail.com>
To: Alex Morcos <morcos@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b33d812e8888405157f4cba
X-Spam-Score: -0.6 (/)
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
X-Headers-End: 1YqNQm-0004sq-9D
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 15:09:46 -0000

--047d7b33d812e8888405157f4cba
Content-Type: text/plain; charset=UTF-8

100% agree, RE hard forks should be hard.

However, it is the paradox of growth, morale and adoption that bitcoin
might never reach the point where it is saturated & expensive to the point
where larger blocks are demanded by 95%+...  simply because people and
companies chose not to adopt bitcoin in the first place due to an unmoving,
[perceived | real] scalability roadblock.


On Thu, May 7, 2015 at 11:04 AM, Alex Morcos <morcos@gmail.com> wrote:

> That strikes me as a dangerous path forward.
>
> I don't actually think there is anything wrong with this: "everybody
> eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and
> we're left with the status quo"
>
> What gives Bitcoin value aren't its technical merits but the fact that
> people believe in it.   The biggest risk here isn't that 20MB blocks will
> be bad or that 1MB blocks will be bad, but that by forcing a hard fork that
> isn't nearly universally agreed upon, we will be damaging that belief.   If
> I strongly believed some hard fork would be better for Bitcoin, say
> permanent inflation of 1% a year to fund mining, and I managed to convince
> 80% of users, miners, businesses and developers to go along with me, I
> would still vote against doing it.  Because that's not nearly universal
> agreement, and it changes what people chose to believe in without their
> consent. Forks should be hard, very hard.  And both sides should recognize
> that belief in the value of Bitcoin might be a fragile thing.   I'd argue
> that if we didn't force through a 20MB fork now, and we ran into major
> network difficulties a year from now and had no other technical solutions,
> that maybe we would get nearly universal agreement, and the businesses and
> users that were driven away by the unusable system would be a short term
> loss in value considerably smaller than the impairment we risk by forcing a
> change.
>
>
>
> On Thu, May 7, 2015 at 10:52 AM, Gavin Andresen <gavinandresen@gmail.com>
> wrote:
>
>> For reference: the blog post that (re)-started this debate, and which
>> links to individual issues, is here:
>>   http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>>
>> In it, I asked people to email me objections I might have missed. I would
>> still appreciate it if people do that; it is impossible to keep up with
>> this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and
>> also have time to respond thoughtfully to the objections raised.
>>
>> I would very much like to find some concrete course of action that we can
>> come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
>> how much transaction volume the main Bitcoin blockchain will be able to
>> support over the next eleven years."
>>
>> I've been pretty clear on what I think is a reasonable compromise (a
>> one-time increase scheduled for early next year), and I have tried to
>> explain why I think it it is the right set of tradeoffs.
>>
>> There ARE tradeoffs here, and the hard question is what process do we use
>> to decide those tradeoffs?  How do we come to consensus? Is it worth my
>> time to spend hours responding thoughtfully to every new objection raised
>> here, or will the same thing happen that happened last year and the year
>> before-- everybody eventually gets tired of arguing
>> angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
>>
>> I AM considering contributing some version of the bigger blocksize-limit
>> hard-fork patch to the Bitcoin-Xt fork (probably  "target a hobbyist with a
>> fast Internet connection, and assume Nelson's law to increase over time),
>> and then encouraging merchants and exchanges and web wallets and
>> individuals who think it strikes a reasonable balance to run it.
>>
>> And then, assuming it became a super-majority of nodes on the network,
>> encourage miners to roll out a soft-fork to start producing bigger blocks
>> and eventually trigger the hard fork.
>>
>> Because ultimately consensus comes down to what software people choose to
>> run.
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

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

<div dir=3D"ltr"><div>100% agree, RE hard forks should be hard.<br><br></di=
v>However, it is the paradox of growth, morale and adoption that bitcoin mi=
ght never reach the point where it is saturated &amp; expensive to the poin=
t where larger blocks are demanded by 95%+...=C2=A0 simply because people a=
nd companies chose not to adopt bitcoin in the first place due to an unmovi=
ng, [perceived | real] scalability roadblock.<br><br></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Thu, May 7, 2015 at 11:04 AM, =
Alex Morcos <span dir=3D"ltr">&lt;<a href=3D"mailto:morcos@gmail.com" targe=
t=3D"_blank">morcos@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">That strikes me as a dangerous path forward.<di=
v><br></div><div>I don&#39;t actually think there is anything wrong with th=
is: &quot;<span style=3D"font-size:12.8000001907349px">everybody eventually=
 gets tired of arguing angels-dancing-on-the-head-of-</span><span style=3D"=
font-size:12.8000001907349px">a-pin, and we&#39;re left with the status quo=
&quot;</span></div><div><span style=3D"font-size:12.8000001907349px"><br></=
span></div><div><span style=3D"font-size:12.8000001907349px">What gives Bit=
coin value aren&#39;t its technical merits but the fact that people believe=
 in it. =C2=A0 The biggest risk here isn&#39;t that 20MB blocks will be bad=
 or that 1MB blocks will be bad, but that by forcing a hard fork that isn&#=
39;t nearly universally agreed upon, we will be damaging that belief. =C2=
=A0 If I strongly believed some hard fork would be better for Bitcoin, say =
permanent inflation of 1% a year to fund mining, and I managed to convince =
80% of users, miners, businesses and developers to go along with me, I woul=
d still vote against doing it.=C2=A0 Because that&#39;s not nearly universa=
l agreement, and it changes what people chose to believe in without their c=
onsent. Forks should be hard, very hard.=C2=A0 And both sides should recogn=
ize that belief in the value of Bitcoin might be a fragile thing. =C2=A0 I&=
#39;d argue that if we didn&#39;t force through a 20MB fork now, and we ran=
 into major network difficulties a year from now and had no other technical=
 solutions, that maybe we would get nearly universal agreement, and the bus=
inesses and users that were driven away by the unusable system would be a s=
hort term loss in value considerably smaller than the impairment we risk by=
 forcing a change.</span></div><div><span style=3D"font-size:12.80000019073=
49px"><br></span></div><div><span style=3D"font-size:12.8000001907349px"><b=
r></span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><div><div class=3D"h5">On Thu, May 7, 2015 at 10:52 AM, Gavin Andresen =
<span dir=3D"ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"=
_blank">gavinandresen@gmail.com</a>&gt;</span> wrote:<br></div></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div class=
=3D"gmail_extra">For reference: the blog post that (re)-started this debate=
, and which links to individual issues, is here:</div><div class=3D"gmail_e=
xtra">=C2=A0=C2=A0<a href=3D"http://gavinandresen.ninja/time-to-roll-out-bi=
gger-blocks" target=3D"_blank">http://gavinandresen.ninja/time-to-roll-out-=
bigger-blocks</a></div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">In it, I asked people to email me objections I might have misse=
d. I would still appreciate it if people do that; it is impossible to keep =
up with this mailing list, /r/bitcoin posts and comments, and #bitcoin-wiza=
rds and also have time to respond thoughtfully to the objections raised.</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I would =
very much like to find some concrete course of action that we can come to c=
onsensus on. Some compromise so we can tell entrepreneurs &quot;THIS is how=
 much transaction volume the main Bitcoin blockchain will be able to suppor=
t over the next eleven years.&quot;<br><br>I&#39;ve been pretty clear on wh=
at I think is a reasonable compromise (a one-time increase scheduled for ea=
rly next year), and I have tried to explain why I think it it is the right =
set of tradeoffs.</div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">There ARE tradeoffs here, and the hard question is what process=
 do we use to decide those tradeoffs?=C2=A0 How do we come to consensus? Is=
 it worth my time to spend hours responding thoughtfully to every new objec=
tion raised here, or will the same thing happen that happened last year and=
 the year before-- everybody eventually gets tired of arguing angels-dancin=
g-on-the-head-of-a-pin, and we&#39;re left with the status quo?</div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I AM considering =
contributing some version of the bigger blocksize-limit hard-fork patch to =
the Bitcoin-Xt fork (probably =C2=A0&quot;target a hobbyist with a fast Int=
ernet connection, and assume Nelson&#39;s law to increase over time), and t=
hen encouraging merchants and exchanges and web wallets and individuals who=
 think it strikes a reasonable balance to run it.</div><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">And then, assuming it became a =
super-majority of nodes on the network, encourage miners to roll out a soft=
-fork to start producing bigger blocks and eventually trigger the hard fork=
.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Beca=
use ultimately consensus comes down to what software people choose to run.<=
/div><span><font color=3D"#888888"><div class=3D"gmail_extra"><div><br></di=
v>-- <br><div>--<br>Gavin Andresen<br></div><div><br></div>
</div></font></span></div>
<br></div></div><span class=3D"">------------------------------------------=
------------------------------------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></span></blockquote></div><br></div>
<br>-----------------------------------------------------------------------=
-------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature">Jeff Garzik<br>Bitcoin core developer and open source evangelis=
t<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" targe=
t=3D"_blank">https://bitpay.com/</a></div>
</div>

--047d7b33d812e8888405157f4cba--