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
|
Return-Path: <bryan@blockcypher.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7E160BD4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 19:59:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com
[209.85.214.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 46BEE7C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 19:59:24 +0000 (UTC)
Received: by obbop1 with SMTP id op1so14102857obb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 12:59:23 -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:date
:message-id:subject:from:to:cc:content-type;
bh=Nikr1vEQTl360y3/qsmAd5G+jg9XV0CDAlCtNoHZ6Rg=;
b=CLsn8zZ6qgIjjFex9Sis0WV86RkswSYRQh1+j81D9QgHsYrqUfHP6PAQDi1OYQg223
qIQ6ZXFZ8XDyHb9SQDTN5WImXjquToJJmYGshY0fBEB2RHVH4YCdZHoC4b6PadY5DO++
JaAXF+KXUXKl85Lx8aLg9XPnn1Vj6hD9eQnmAytgb2szrrPW62IftR9Vv87mtTB5IYd1
pLe9VLIQjc+MrnPlxY7EsseJ3YeBPns5z1QD/TBCuN03HeSm5OPPERBS6NJSLoYvEzdH
DI5hYpE8tGPb/OE7EGthEgY2zBaibsjvygLuNR6bBIuh8JJ4fIk61IooG2pgeRIxu9wP
ig4g==
X-Gm-Message-State: ALoCoQm44ollPRtXH5TMACuUDMB7qCpJ52Fo1soPk7rXXOzQLb7Y45r1D+LHiiy+T5R9dgb7Ls6L
MIME-Version: 1.0
X-Received: by 10.182.246.9 with SMTP id xs9mr18719786obc.45.1435694363620;
Tue, 30 Jun 2015 12:59:23 -0700 (PDT)
Received: by 10.182.135.8 with HTTP; Tue, 30 Jun 2015 12:59:23 -0700 (PDT)
In-Reply-To: <CALgxB7sPcRT5wgsEb2BkfvPjN98uiea6fe+JehCAW1BJUpUPEA@mail.gmail.com>
References: <CALgxB7uvtKCNM-nH+aqqPa4KNf5O6Gx4GmgZY7Oq8=A24wCrfA@mail.gmail.com>
<5592C0A3.8050008@mail.bihthai.net>
<20150630162526.GA8479@savin.petertodd.org>
<CALgxB7sPcRT5wgsEb2BkfvPjN98uiea6fe+JehCAW1BJUpUPEA@mail.gmail.com>
Date: Tue, 30 Jun 2015 12:59:23 -0700
Message-ID: <CANeMN=-m=2iRA_G8QSN1cmY7PuhoPjULZAFRNmBWtW63sxrKPw@mail.gmail.com>
From: Bryan Cheng <bryan@blockcypher.com>
To: Michael Naber <mickeybob@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c306ee8ccf500519c1a4a6
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] Block size increase oppositionists: please
clearly define what you need done to increase block size to a static 8MB,
and help do it
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: Tue, 30 Jun 2015 19:59:25 -0000
--001a11c306ee8ccf500519c1a4a6
Content-Type: text/plain; charset=UTF-8
One thing that seems to have been forgotten is that the 1MB block size does
not represent any particular rigorous design choice; it is purely arbitrary.
It does not represent any type of technical sweet-spot; it neither falls
under any reasonable MTU to prevent TCP fragmentation, nor does it
guarantee in any unique way ease of transmission or lower latency. Chinese
mining pool operators, noted as one of the more constrained stakeholders in
this decision, have indicated that 8MB is a reasonable compromise in their
situation. Unless individuals with specific, concrete use cases come
forward with exactly how they will be marginalized by blocks in the 1-8MB
range, we should consider 8MB the minimum applicable size for technical
objections to raising the block size from a network propagation point of
view.
It also does not represent any kind of economic sweet spot. If we accept
the arguments on the mailing list that economic incentives for the creation
of the fee market depend entirely on a single variable, the scarcity of
space for transactions in a block, we should be talking about _decreasing_
the block size. In reality, this is clearly laughable. The real economic
analysis would consist of a balance between the space for transactions in a
block, the number of transactions being attempted at any given time, and
the block subsidy, among many other factors. Viewing it in this light, the
chance that 1MB by some divine miracle is the perfect balance of those
economic considerations becomes exceedingly small.
(Personally, I believe that increasing the block size has a greater chance
of creating a fee market after coinbase subsidies decline, as having
competition for space in a block depends not only on the number of
transactions that fit in the block, but also the number of people
attempting to spend; if success rates fall dramatically, significantly
fewer people will attempt to transact bitcoin. However, this is a
discussion for another post).
If we stop considering 1MB to be some magic number, perhaps we can enter
into a real discussion about finding what the right sweet spot is. We very
well may decide that 1MB is _too big_; what should not be acceptable is
conflating pressures to decrease the block size with reasons for inaction
altogether. The end game of this debate should be to decide the new block
size that balances, within reason, the various pressures in every direction.
On Tue, Jun 30, 2015 at 9:35 AM, Michael Naber <mickeybob@gmail.com> wrote:
> Re: Why bother doubling capacity? So that we could have 2x more network
> participants of course.
>
> Re: No clear way to scaling beyond that: Computers are getting more
> capable aren't they? We'll increase capacity along with hardware.
>
> It's a good thing to scale the network if technology permits it. How can
> you argue with that?
>
>
> On Tue, Jun 30, 2015 at 12:25 PM, Peter Todd <pete@petertodd.org> wrote:
>
>> On Tue, Jun 30, 2015 at 11:15:31PM +0700, Venzen Khaosan wrote:
>> > > Do what's best for Bitcoin and define what needs to get done to
>> > > agree to a simple block size increase to a static 8MB.
>> >
>> > And this then leads back to the core issue: if an 8MB blocksize
>> > excludes many on this list from testnet, then the proposed 8MB blocks
>> > will exclude a lot of mainnet participants (miners) and degrade the
>> > quality of diversity and decentralization.
>> >
>> > How about testing at double the capacity: 2MB?
>>
>> Which of course raises another issue: if that was the plan, then all you
>> can do is double capacity, with no clear way to scaling beyond that.
>> Why bother?
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 00000000000000001599522de3e8ed28f0189ddccfa1d6db5eb380cacffc79d7
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11c306ee8ccf500519c1a4a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">One thing that seems to have been forgotten is that the 1M=
B block size does not represent any particular rigorous design choice; it i=
s purely arbitrary.<div><br></div><div>It does not represent any type of te=
chnical sweet-spot; it neither falls under any reasonable MTU to prevent TC=
P fragmentation, nor does it guarantee in any unique way ease of transmissi=
on or lower latency. Chinese mining pool operators, noted as one of the mor=
e constrained stakeholders in this decision, have indicated that 8MB is a r=
easonable compromise in their situation. Unless individuals with specific, =
concrete use cases come forward with exactly how they will be marginalized =
by blocks in the 1-8MB range, we should consider 8MB the minimum applicable=
size for technical objections to raising the block size from a network pro=
pagation point of view.=C2=A0</div><div><br></div><div>It also does not rep=
resent any kind of economic sweet spot. If we accept the arguments on the m=
ailing list that economic incentives for the creation of the fee market dep=
end entirely on a single variable, the scarcity of space for transactions i=
n a block, we should be talking about _decreasing_ the block size. In reali=
ty, this is clearly laughable. The real economic analysis would consist of =
a balance between the space for transactions in a block, the number of tran=
sactions being attempted at any given time, and the block subsidy, among ma=
ny other factors. Viewing it in this light, the chance that 1MB by some div=
ine miracle is the perfect balance of those economic considerations becomes=
exceedingly small.=C2=A0</div><div><br></div><div>(Personally, I believe t=
hat increasing the block size has a greater chance of creating a fee market=
after coinbase subsidies decline, as having competition for space in a blo=
ck depends not only on the number of transactions that fit in the block, bu=
t also the number of people attempting to spend; if success rates fall dram=
atically, significantly fewer people will attempt to transact bitcoin. Howe=
ver, this is a discussion for another post).</div><div><br></div><div>If we=
stop considering 1MB to be some magic number, perhaps we can enter into a =
real discussion about finding what the right sweet spot is. We very well ma=
y decide that 1MB is _too big_; what should not be acceptable is conflating=
pressures to decrease the block size with reasons for inaction altogether.=
The end game of this debate should be to decide the new block size that ba=
lances, within reason, the various pressures in every direction.</div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 30, 2015 a=
t 9:35 AM, Michael Naber <span dir=3D"ltr"><<a href=3D"mailto:mickeybob@=
gmail.com" target=3D"_blank">mickeybob@gmail.com</a>></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">Re: Why bother doubling capa=
city? So that we could have 2x more network participants of course.<div><br=
></div><div>Re: No clear way to scaling beyond that: Computers are getting =
more capable aren't they? We'll increase capacity along with hardwa=
re.</div><div><br></div><div>It's a good thing to scale the network if =
technology permits it. How can you argue with that?<br></div><div><div><div=
><br></div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jun 30, 2015 at 12:25 PM, Peter Todd <span dir=3D"ltr"><<a h=
ref=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><span>On Tue, Jun 30, 2015 at 11:15:3=
1PM +0700, Venzen Khaosan wrote:<br>
> > Do what's best for Bitcoin and define what needs to get done =
to<br>
> > agree to a simple block size increase to a static 8MB.<br>
><br>
> And this then leads back to the core issue: if an 8MB blocksize<br>
> excludes many on this list from testnet, then the proposed 8MB blocks<=
br>
> will exclude a lot of mainnet participants (miners) and degrade the<br=
>
> quality of diversity and decentralization.<br>
><br>
> How about testing at double the capacity: 2MB?<br>
<br>
</span>Which of course raises another issue: if that was the plan, then all=
you<br>
can do is double capacity, with no clear way to scaling beyond that.<br>
Why bother?<br>
<span><font color=3D"#888888"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
00000000000000001599522de3e8ed28f0189ddccfa1d6db5eb380cacffc79d7<br>
</font></span></blockquote></div><br></div></div></div></div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
--001a11c306ee8ccf500519c1a4a6--
|
