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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1YymUi-0002SN-El
for bitcoin-development@lists.sourceforge.net;
Sat, 30 May 2015 19:32:32 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bluematt.me
designates 192.241.179.72 as permitted sender)
client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me;
helo=mail.bluematt.me;
Received: from mail.bluematt.me ([192.241.179.72])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YymUf-0000Ro-Q7
for bitcoin-development@lists.sourceforge.net;
Sat, 30 May 2015 19:32:32 +0000
Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id B717654DDE;
Sat, 30 May 2015 19:32:23 +0000 (UTC)
Message-ID: <556A1046.50807@bluematt.me>
Date: Sat, 30 May 2015 19:32:22 +0000
From: Matt Corallo <bitcoin-list@bluematt.me>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Gavin Andresen <gavinandresen@gmail.com>
References: <554BE0E1.5030001@bluematt.me> <CABsx9T2ysKj5HVbN_7_o33fMehs4KH6E_R583Mt_VPC4gDA0LQ@mail.gmail.com> <5568F567.3050608@bluematt.me>
<CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
In-Reply-To: <CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.5 (-)
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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YymUf-0000Ro-Q7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
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: Sat, 30 May 2015 19:32:32 -0000
On 05/29/15 23:48, Gavin Andresen wrote:
> On Fri, May 29, 2015 at 7:25 PM, Matt Corallo <bitcoin-list@bluematt.me
> <mailto:bitcoin-list@bluematt.me>> wrote:
>=20
> Sadly, this is very far from the whole story. The issue of miners
> optimizing for returns has been discussed several times during this
> discussion, and, sadly, miners who are geographically colocated who=
are
> optimizing for returns with a free-floating blocksize will optimize=
away
> 50% of the network!
>=20
>=20
> I must have missed that analysis-- link please? Or summary of HOW they
> will optimize away 50% of the network?
>=20
> Or are you assuming that 50% of the network is colocated... (which is a
> potential problem independent of blocksize)
If, for example, the majority of miners are in China (they are), and
there is really poor connectivity in and out of China (there is) and a
miner naively optimizes for profit, they will create blocks which are
large and take a while to relay out of China. By simple trial-and-error
an individual large miner might notice that when they create larger
blocks which fork off miners in other parts of the world, they get more
income. Obviously forking off 50% of the network would be a rather
extreme situation and assumes all kinds of simplified models, but it
shows that the incentives here are very far from aligned, and your
simplified good-behavior models are very far from convincing.
>=20
> >
> > In addition, I'd expect to
> > see analysis of how these systems perform in the worst-case, =
not just
> > packet-loss-wise, but in the face of miners attempting to bre=
ak the
> > system.
> >
> >
> > See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigge=
r-miners for
> > analysis of "but that means bigger miners can get an advantage" a=
rgument.
> >
> > Executive summary: if little miners are stupid and produce huge b=
locks,
> > then yes, big miners have an advantage.
>=20
> I'll talk about transaction fees in a second, but there are several
> problems with this already. As pointed out in the original mail, gf=
w has
> already been known to interfere with Bitcoin P2P traffic. So now by
> "little" miners, you mean any miner who is not located in mainland
> China? Whats worse, the disadvantage is symmetric - little miners a=
re at
> a disadvantage when *anyone* mines a bigger block, and miners dont =
even
> have to be "evil" for this to happen - just optimize for profits.
>=20
>=20
> But the disadvantage is tiny. And essentially zero if they connect to
> your fast relay network (or anything like it).
>=20
The disadvantage is small with 1MB blocks, but already non-zero. 20MB
blocks are much, much worse (lots of things here dont scale linearly,
even just transfer over a high-packet-loss-link). I mentioned this in my
original email as something which doesnt make me comfortable with 20MB
blocks, but something which needs simulation and study, and might
actually be just fine!
>=20
> > But they're not, so they won't.
>=20
> I dont know what you're referring to with this. Are you claiming li=
ttle
> miners today optimize for relay times and have good visibility into=
the
> Bitcoin network and calculate an optimal block size based on this (=
or
> would with a 20MB block size)?
>=20
>=20
> Do you have another explanation for why miners choose to leave
> fee-paying transactions in their mempool and create small blocks?
Defaults? Dumb designs? Most miners just use the default 750K blocks, as
far as I can tell, other miners probably didnt see transactions relayed
across several hops or so, and a select few miners are doing crazy
things like making their blocks fit in a single packet to cross the gfw,
but that is probably overkill and not well-researched.
> > Until the block reward goes away, and assuming transaction fees b=
ecome
> > an important source of revenue for miners.
> > I think it is too early to worry about that; see:
> >
> > http://gavinandresen.ninja/when-the-block-reward-goes-away
>=20
> You dont make any points here with which I can argue, but let me re=
spond
> with the reason /I/ think it is a problem worth thinking a little b=
it
> about...If we increase the blocksize sufficiently such that transac=
tion
> fees are not the way in which miners make their money
>=20
>=20
> I'm not suggesting that we increase the blocksize sufficiently such tha=
t
> transaction fees are not the way in which miners make their money.
>=20
> I'm suggesting the blocksize be increased to 20MB (and then doubled
> every couple of years).
Do you have convincing evidence that at 20MB miners will be able to
break even on transaction fees for a long time? (The answer is no
because no one has any idea how bitcoin transaction volumes are going to
scale, period.)
> And "in which miners make their money" is the wrong metric-- we want
> enough mining so the network to be "secure enough" against double-spend=
s.
Sure, do you have a value of hashpower which is "secure enough" (which
is a whole other rabbit hole to go down...).
>=20
> , then either
> miners are not being funded (ie hashpower has to drop to very littl=
e),
> or the only people mining/funding miners are large orgs who are
> "running" Bitcoin (ie the web wallets, payment processors, big
> merchants, and exchanges of the world). Sadly, this is no longer a
> decentralized Bitcoin and is, in fact, pretty much how the banking =
world
> works today.
>=20
>=20
> Even if we end up in a world where only big companies can run full node=
s
> (and I am NOT NOT NOT NOT NOT proposing any such thing), there is a
> difference-- you don't need permission to "open up a bank" on the
> Bitcoin network.
>=20
Oh? You mention at http://gavinandresen.ninja/bigger-blocks-another-way
that "I struggle with wanting to stay true to Satoshi=E2=80=99s original =
vision
of Bitcoin as a system that scales up to Visa-level transaction volume".
That is in direct contradiction.
> I'm not sure who, if anyone, claims Bitcoin is novel or interesting=
for
> any reason other than its decentralization properties, and, in a wo=
rld
> which you are apparently proposing, the "natural" course of things =
is to
> very strongly centralize.
>=20
>=20
> > * I'd very much like to see someone working on better scalin=
g
> > technology, both in terms of development and in terms of gett=
ing
> > traction in the marketplace.
> >
> >
> > Ok. What does this have to do with the max block size?
> >
> > Are you arguing that work won't happen if the max block size incr=
eases?
>=20
> Yes, I am arguing that by increasing the blocksize the incentives t=
o
> actually make Bitcoin scale go away. Even if amazing technologies g=
et
> built, no one will have any reason to use them.
>=20
>=20
> Ok, I wrote about that here:
>=20
> http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea
>=20
"it is not a panacea", but everyone in the community seems to be taking
it as one. You've claimed many times that many of the big
webwallet/payment processors/etc have been coming to you and saying they
need bigger block sizes to continue operating. In reality, they dont, it
just makes it easier.
Matt
|
