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
|
Return-Path: <elliot.olds@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5843DFF
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 07:29:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com
[209.85.223.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 808027C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 07:29:51 +0000 (UTC)
Received: by iodd187 with SMTP id d187so40972122iod.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Aug 2015 00:29:51 -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=aRexV9FAGex++jenREhg5Sqd/6oRkCKykp9O0mjPanI=;
b=IIyKlhv17OgagItZ0f4T86WN1wXTXDljLbWQZXxqPKA2wJvd4JezjzTQcdlAKQdHuk
Ja8XxY+THdAm1F4QeRxI/jZf6rjEaKXvndw/+NgNXa9rXkmdVeyIMdHqOzxgnGjZXQXm
+xg7tPXAKFWwGXFlciPcqswk/SZOFYzjJMi5T2cakm2YYXfkIfqkY3q1BXTA77MrL9/l
jHiZ26ztPaduV0a9P+DeuE/vJND7kkVHm2YKSYvAZeacnK4TNfqU+aKtXK1Zhc1AOGud
EXfHh4BzWSsj0euIYMpqJYZd2qMqM74CdwOXNehFL+2P3/HzxaRgIkFRkb6Y/4hid+/l
scqA==
MIME-Version: 1.0
X-Received: by 10.107.17.170 with SMTP id 42mr8716417ior.21.1438759790968;
Wed, 05 Aug 2015 00:29:50 -0700 (PDT)
Received: by 10.79.97.4 with HTTP; Wed, 5 Aug 2015 00:29:50 -0700 (PDT)
In-Reply-To: <CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@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>
<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
<CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com>
Date: Wed, 5 Aug 2015 00:29:50 -0700
Message-ID: <CA+BnGuFNOjzLaiPPnUSi-rkU94UMgmP30Si8N3oBSYG0q8j-_w@mail.gmail.com>
From: Elliot Olds <elliot.olds@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113eca7e42064e051c8b5eb4
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_05,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
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: Wed, 05 Aug 2015 07:29:52 -0000
--001a113eca7e42064e051c8b5eb4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Aug 4, 2015 at 4:59 AM, Jorge Tim=C3=B3n <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Also I don't think "hitting the limit" must be necessarily harmful and
> if it is, I don't understand why hitting it at 1MB will be more
> harmful than hitting it at 2MB, 8MB or 8GB.
I don't think merely hitting the limit is bad. The level of tx fees in
equilibrium give some clue as to the level of harm being done. If fees are
at $5/tx at 1MB, it's about as bad as if fees are at $5/tx at 4MB.
There is NO criterion based on mining centralization to decide between
> 2 sizes in favor of the small one.
> It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be effectively
> any limit in the long term and Bitcoin will probably fail in its
> decentralization goals.
> I think its the proponents of a blocksize change who should propose
> such a criterion and now they have the tools to simulate different
> block sizes.
>
In the absence of harder data, it might be interesting to use these
simulations to graph centralization pressure as a function of bandwidth
cost over time (or other historical variables that affect centralization).
For instance, look at how high centralization pressure was in 2009
according to the simulations, given how cheap/available bandwidth was then,
compared to 2010, 2011, etc. Then we could figure out: given today's
bandwidth situation, what size blocks right now would give us the same
centralization pressure that we had in 2011, 2012, 2013, etc?
Of course this doesn't mean we should blindly assume that the level of
centralization pressure in 2012 was acceptable, and therefore any block
size increase that results in the same amount of pressure now should be
acceptable. But it might lead to a more productive discussion.
> I want us to simulate many blocksizes before rushing into a decision
> (specially because I disagree that taking a decision there is urgent
> in the first place).
IMO it is not urgent if the core devs are committed to reacting to a huge
spike in tx fees with a modest block size increase in a relatively short
time frame, if they judge the centralization risks of that increase to be
small. Greg Maxwell posted on reddit a while back something to the effect
of "the big block advocates are overstating the urgency of the block size
increase, because if there was actually a situation that required us to
increase block size, we could make the increase when it was actually
needed." I found that somewhat persuasive, but I am concerned that I
haven't seen any discussion of what the "let's wait for now" camp would
consider a valid reason to increase block size in the short term, and how
they'd make the tradeoff with tx fees or whatever else was necessitating
the increase.
Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow knew
with certainty that increasing to 4MB would result in a 20 cent/tx
equilibrium that would last for a year (otherwise fees would stay around $5
for that year), would you be in favor of an increase to 4MB?
For those familiar with the distinction between near/far mode thinking
popularized by Robin Hanson: focusing on concrete examples like this
encourages problem solving and consensus, and focusing on abstract
principles (like decentralization vs. usability in general) leads to people
toward using argument to signal their alliances and reduce the status of
their opponents. I think it'd be very helpful if more 1MB advocates
described what exactly would make them say "OK, in this situation a block
size increase is needed, we should do one quickly!", and also if
Gavin/Mike/Jeff described what hypothetical scenarios and/or test results
would make them want to stick with 1MB blocks for now.
--001a113eca7e42064e051c8b5eb4
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=
ue, Aug 4, 2015 at 4:59 AM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>></span> wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
Also I don't think "hitting the limit" must be necessarily ha=
rmful and<br>
if it is, I don't understand why hitting it at 1MB will be more<br>
harmful than hitting it at 2MB, 8MB or 8GB.</blockquote><div><br></div><div=
>I don't think merely hitting the limit is bad. The level of tx fees in=
equilibrium give some clue as to the level of harm being done. If fees are=
at $5/tx at 1MB, it's about as bad as if fees are at $5/tx at 4MB.=C2=
=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is NO criterion based on mining centralization to decide between<br>
2 sizes in favor of the small one.<br>
It seems like the rationale it's always "the bigger the better&quo=
t; and<br>
the only limitation is what a few people concerned with mining<br>
centralization (while they still have time to discuss this) are<br>
willing to accept. If that's the case, then there won't be effectiv=
ely<br>
any limit in the long term and Bitcoin will probably fail in its<br>
decentralization goals.<br>
I think its the proponents of a blocksize change who should propose<br>
such a criterion and now they have the tools to simulate different<br>
block sizes.<br></blockquote><div><br></div><div>In the absence of harder d=
ata, it might be interesting to use these simulations to graph centralizati=
on pressure as a function of bandwidth cost over time (or other historical =
variables that affect centralization). For instance, look at how high centr=
alization pressure was in 2009 according to the simulations, given how chea=
p/available bandwidth was then, compared to 2010, 2011, etc. Then we could =
figure out: given today's bandwidth situation, what size blocks right n=
ow would give us the same centralization pressure that we had in 2011, 2012=
, 2013, etc?</div><div><br></div><div>Of course this doesn't mean we sh=
ould blindly assume that the level of centralization pressure in 2012 was a=
cceptable, and therefore any block size increase that results in the same a=
mount of pressure now should be acceptable. But it might lead to a more pro=
ductive discussion.</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">
I want us to simulate many blocksizes before rushing into a decision<br>
(specially because I disagree that taking a decision there is urgent<br>
in the first place).</blockquote><div><br></div><div>IMO it is not urgent i=
f the core devs are committed to reacting to a huge spike in tx fees with a=
modest block size increase in a relatively short time frame, if they judge=
the centralization risks of that increase to be small. Greg Maxwell posted=
on reddit a while back something to the effect of "the big block advo=
cates are overstating the urgency of the block size increase, because if th=
ere was actually a situation that required us to increase block size, we co=
uld make the increase when it was actually needed." I found that somew=
hat persuasive, but I am concerned that I haven't seen any discussion o=
f what the "let's wait for now" camp would consider a valid r=
eason to increase block size in the short term, and how they'd make the=
tradeoff with tx fees or whatever else was necessitating the increase.=C2=
=A0</div><div><br></div><div>Jorge, if a fee equilibrium developed at 1MB o=
f $5/tx, and you somehow knew with certainty that increasing to 4MB would r=
esult in a 20 cent/tx equilibrium that would last for a year (otherwise fee=
s would stay around $5 for that year), would you be in favor of an increase=
to 4MB?=C2=A0</div><div><br></div><div>For those familiar with the distinc=
tion between near/far mode thinking popularized by Robin Hanson: focusing o=
n concrete examples like this encourages problem solving and consensus, and=
focusing on abstract principles (like decentralization vs. usability in ge=
neral) leads to people toward using argument to signal their alliances and =
reduce the status of their opponents. I think it'd be very helpful if m=
ore 1MB advocates described what exactly would make them say "OK, in t=
his situation a block size increase is needed, we should do one quickly!&qu=
ot;, and also if Gavin/Mike/Jeff described what hypothetical scenarios and/=
or test results would make them want to stick with 1MB blocks for now.</div=
><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div=
><div><br></div></div></div></div>
--001a113eca7e42064e051c8b5eb4--
|
