summaryrefslogtreecommitdiff
path: root/bd/8cbe356e051e4b7f12dc6f789451e7dec647ea
blob: ecc1133c6bf301c6b2eb46234490b6660d8d6a2f (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
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 1F5C5405
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 10:16:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
	[209.85.223.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F092FEE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 10:16:46 +0000 (UTC)
Received: by ioii16 with SMTP id i16so80744972ioi.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 03:16:46 -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=3vxxKpGRqLr/ki9mCTgQGyeCbUoWt2z0v5kby2ZBLAE=;
	b=pm+X5IogYfIvLtj1yuDlqqUFaxTuD2t0Mk2BScGp0pPtOyDjWUfPcqlc2gBP6b3+2o
	uNu+PJrUjFCJOcLpMSINhQESlsGmZhomYDm75MJrYCKGPLeg3Ddpp7YupX3+vRK/zwQC
	2LASyllTBSghOs3LJ9Iq7q4/kEG5kFhKV1RwM=
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=3vxxKpGRqLr/ki9mCTgQGyeCbUoWt2z0v5kby2ZBLAE=;
	b=GLq5EeMiE8DOvA+PeoR2ts05AcrOg1f+p59QZC1MF8Ke02xzUCkNWDvMkyY451PshQ
	uHRbDxitbRUmzDtkPGknJFrIC2JOghaaZlz7V3KjewPBCdSdCBzcZt59F2+1ICydFrDZ
	Iu6zvuJhxpujqa5dFQNAWB79Zn5lkwhTbY/PjuIBtAEwL+O+UEje3z7dw81dkGjz06H6
	TR4WQyo7URXuuB+STsfXGFftKbrwWU9FcvtMF9f911bk8jAvYdbslteWJn2Au241fSCK
	RijpFZnW00wszAgf1ZqSy5NYcbnFL533KwR32HGwml2pRwGOMWG3qNEWUeE5p6BioABS
	xWFw==
X-Gm-Message-State: ALoCoQkcFwBbpGAiJ+tR5AwP+MCzJKGFYTarH4shdKJ7Fn0KHwVtZ3mEjL6k1JmlsG4ZB2p51QCf
MIME-Version: 1.0
X-Received: by 10.107.135.193 with SMTP id r62mr3198481ioi.29.1438337806445;
	Fri, 31 Jul 2015 03:16:46 -0700 (PDT)
Received: by 10.50.108.111 with HTTP; Fri, 31 Jul 2015 03:16:46 -0700 (PDT)
In-Reply-To: <CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
	<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
	<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
Date: Fri, 31 Jul 2015 12:16:46 +0200
Message-ID: <CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a113eceb2054cb8051c291e9f
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_40,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 Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
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: Fri, 31 Jul 2015 10:16:48 -0000

--001a113eceb2054cb8051c291e9f
Content-Type: text/plain; charset=UTF-8

I agree with Gavin - whilst it's great that a Blockstream employee has
finally made a realistic proposal (i.e. not "let's all use Lightning") -
this BIP is virtually the same as keeping the 1mb cap.

> Well, centralization of mining is already terrible. I see no reason why we
> should encourage making it worse.
>
Centralization of mining has been a continual gripe since Slush first
invented pooled mining. There has never been a time after that when people
weren't talking about the centralisation of mining, and back then blocks
were ~10kb.

I see constant assertions that node count, mining centralisation,
developers not using Bitcoin Core in their own businesses etc is all to do
with block sizes. But nobody has shown that. Nobody has even laid the
groundwork for that. Verifying blocks takes milliseconds and downloading
them takes seconds everywhere except, apparently, China: this resource
usage is trivial.

Yet developers, miners and users even outside of China routinely delegate
validation to others. Often for quite understandable technical reasons that
have nothing to do with block sizes.

So I see no reason why arbitrarily capping the block size will move the
needle on these metrics. Trying to arrest the growth of Bitcoin for
everyone won't suddenly make Bitcoin-Qt a competitive wallet, or make
service devs migrate away from chain.com, or make merchants stop using
BitPay.

We need to accept that, and all previous proposals I've seen don't seem to
> do that.
>
I think that's a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth
you're right, some use cases will be priced out. I initiated the
micropayment channels project (along with Matt, tip of the hat)
specifically to optimise a certain class of transactions. Even with 8mb+
blocks, there will still be a need for micropayment channels, centralised
exchange platforms and other forms of off chain transaction.

If Bitcoin needs to support a large scale, it already failed.
>
It hasn't even been tried.

The desperately sad thing about all of this is that there's going to be a
fork, and yet I think most of us agree on most things.  But we don't agree
on this.

Bitcoin can support a large scale and it must, for all sorts of reasons.
Amongst others:

   1. Currencies have network effects. A currency that has few users is
   simply not competitive with currencies that have many. There's no such
   thing as a settlement currency for high value transactions only, as
   evidenced by the ever-dropping importance of gold.


   2. A decentralised currency that the vast majority can't use doesn't
   change the amount of centralisation in the world. Most people will still
   end up using banks, with all the normal problems. You cannot solve a
   problem by creating a theoretically pure solution that's out of reach of
   ordinary people: just ask academic cryptographers!


   3. Growth is a part of the social contract. It always has been.

   The best quote Gregory can find to suggest Satoshi wanted small blocks
   is a one sentence hypothetical example about what *might* happen if
   Bitcoin users became "tyrannical" as a result of non-financial transactions
   being stuffed in the block chain. That position makes sense because his
   scaling arguments assuming payment-network-sized traffic and throwing DNS
   systems or whatever into the mix could invalidate those arguments, in the
   absence of merged mining. But Satoshi did invent merged mining, and so
   there's no need for Bitcoin users to get "tyrannical": his original
   arguments still hold.


   4. All the plans for some kind of ultra-throttled Bitcoin network used
   for infrequent transactions neglect to ask where the infrastructure for
   that will come from. The network of exchanges, payment processors and
   startups that are paying people to build infrastructure are all based on
   the assumption that the market will grow significantly. It's a gamble at
   best because Bitcoin's success is not guaranteed, but if the block chain
   cannot grow it's a gamble that is guaranteed to be lost.

   So why should anyone go through the massive hassle of setting up
   exchanges, without the lure of large future profits?


   5. Bitcoin needs users, lots of them, for its political survival. There
   are many people out there who would like to see digital cash disappear, or
   be regulated out of existence. They will argue for that in front of
   governments and courts .... some already are. And if they're going to lose
   those arguments, the political and economic damage of getting rid of
   Bitcoin must be large enough to make people think twice. That means it
   needs supporters, it needs innovative services, it needs companies, and it
   needs legal users making legal payments: as many of them as possible.

   If Bitcoin is a tiny, obscure currency used by drug dealers and a
   handful of crypto-at-any-cost geeks, the cost of simply banning it outright
   will seem trivial and the hammer will drop. There won't be a large scale
   payment network OR a high-value settlement network. And then the world is
   really screwed, because nobody will get a second chance for a very long
   time.

--001a113eceb2054cb8051c291e9f
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"><div=
>I agree with Gavin - whilst it&#39;s great that a Blockstream employee has=
 finally made a realistic proposal (i.e. not &quot;let&#39;s all use Lightn=
ing&quot;) - this BIP is virtually the same as keeping the 1mb cap.</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><p dir=3D"ltr">Well, centralization of mining =
is already terrible. I see no reason why we should encourage making it wors=
e.</p></blockquote><div>Centralization of mining has been a continual gripe=
 since Slush first invented pooled mining. There has never been a time afte=
r that when people weren&#39;t talking about the centralisation of mining, =
and back then blocks were ~10kb.=C2=A0</div><div><br></div><div>I see const=
ant assertions that node count, mining centralisation, developers not using=
 Bitcoin Core in their own businesses etc is all to do with block sizes. Bu=
t nobody has shown that. Nobody has even laid the groundwork for that. Veri=
fying blocks takes milliseconds and downloading them takes seconds everywhe=
re except, apparently, China: this resource usage is trivial.=C2=A0</div><d=
iv><br></div><div>Yet developers, miners and users even outside of China ro=
utinely delegate validation to others. Often for quite understandable techn=
ical reasons that have nothing to do with block sizes.</div><div><br></div>=
<div>So I see no reason why arbitrarily capping the block size will move th=
e needle on these metrics. Trying to arrest the growth of Bitcoin for every=
one won&#39;t suddenly make Bitcoin-Qt a competitive wallet, or make servic=
e devs migrate away from <a href=3D"http://chain.com">chain.com</a>, or mak=
e merchants stop using BitPay.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><p dir=3D"ltr">We need to accept that, and all previous proposals I&=
#39;ve seen don&#39;t seem to do that.</p></blockquote><div>I think that&#3=
9;s a bit unfair: BIP 101 keeps a cap. Even with 8mb+growth you&#39;re righ=
t, some use cases will be priced out. I initiated the micropayment channels=
 project (along with Matt, tip of the hat) specifically to optimise a certa=
in class of transactions. Even with 8mb+ blocks, there will still be a need=
 for micropayment channels, centralised exchange platforms and other forms =
of off chain transaction.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><p dir=3D"ltr">If Bitcoin needs to support a large scale, it already fail=
ed.<br></p></blockquote><div>It hasn&#39;t even been tried.=C2=A0</div><div=
><br></div><div><div>The desperately sad thing about all of this is that th=
ere&#39;s going to be a fork, and yet I think most of us agree on most thin=
gs.=C2=A0 But we don&#39;t agree on this.=C2=A0</div><div><br></div><div>Bi=
tcoin can support a large scale and it must, for all sorts of reasons. Amon=
gst others:</div><div><ol><li>Currencies have network effects. A currency t=
hat has few users is simply not competitive with currencies that have many.=
 There&#39;s no such thing as a settlement currency for high value transact=
ions only, as evidenced by the ever-dropping importance of gold.<br><br><br=
></li><li>A decentralised currency that the vast majority can&#39;t use doe=
sn&#39;t change the amount of centralisation in the world. Most people will=
 still end up using banks, with all the normal problems. You cannot solve a=
 problem by creating a theoretically pure solution that&#39;s out of reach =
of ordinary people: just ask academic cryptographers!<br><br><br></li><li>G=
rowth is a part of the social contract. It always has been.=C2=A0<br><br>Th=
e best quote Gregory can find to suggest Satoshi wanted small blocks is a o=
ne sentence hypothetical example about what <i>might</i> happen if Bitcoin =
users became &quot;tyrannical&quot; as a result of non-financial transactio=
ns being stuffed in the block chain. That position makes sense because his =
scaling arguments assuming payment-network-sized traffic and throwing DNS s=
ystems or whatever into the mix could invalidate those arguments, in the ab=
sence of merged mining. But Satoshi did invent merged mining, and so there&=
#39;s no need for Bitcoin users to get &quot;tyrannical&quot;: his original=
 arguments still hold.<br><br><br></li><li>All the plans for some kind of u=
ltra-throttled Bitcoin network used for infrequent transactions neglect to =
ask where the infrastructure for that will come from. The network of exchan=
ges, payment processors and startups that are paying people to build infras=
tructure are all=C2=A0based on the assumption that the market will grow sig=
nificantly. It&#39;s a gamble at best because Bitcoin&#39;s success is not =
guaranteed, but if the block chain cannot grow it&#39;s a gamble that is gu=
aranteed to be lost.<br><br>So why should anyone go through the massive has=
sle of setting up exchanges, without the lure of large future profits?<br><=
br><br></li><li>Bitcoin needs users, lots of them, for its political surviv=
al. There are many people out there who would like to see digital cash disa=
ppear, or be regulated out of existence. They will argue for that in front =
of governments and courts .... some already are. And if they&#39;re going t=
o lose those arguments, the political and economic damage of getting rid of=
 Bitcoin must be large enough to make people think twice. That means it nee=
ds supporters, it needs innovative services, it needs companies, and it nee=
ds legal users making legal payments: as many of them as possible.<br><br>I=
f Bitcoin is a tiny, obscure currency used by drug dealers and a handful of=
 crypto-at-any-cost geeks, the cost of simply banning it outright will seem=
 trivial and the hammer will drop. There won&#39;t be a large scale payment=
 network OR a high-value settlement network. And then the world is really s=
crewed, because nobody will get a second chance for a very long time.</li><=
/ol></div><div><br></div><div><br></div></div></div></div></div>

--001a113eceb2054cb8051c291e9f--