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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stephencalebmorse@gmail.com>) id 1YzUya-0003OC-No
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 19:02:20 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.169 as permitted sender)
client-ip=209.85.160.169;
envelope-from=stephencalebmorse@gmail.com;
helo=mail-yk0-f169.google.com;
Received: from mail-yk0-f169.google.com ([209.85.160.169])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzUyY-0002DI-0E
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 19:02:20 +0000
Received: by yked142 with SMTP id d142so46470600yke.3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 12:02:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.170.134.1 with SMTP id a1mr3404068ykc.30.1433185332434; Mon,
01 Jun 2015 12:02:12 -0700 (PDT)
Received: by 10.13.245.70 with HTTP; Mon, 1 Jun 2015 12:02:12 -0700 (PDT)
In-Reply-To: <CANe1mWz_wDAFL2piyLeOxEnMxHCQaTnGLQA6f9jZvLEmbMj6Zw@mail.gmail.com>
References: <CANe1mWz_wDAFL2piyLeOxEnMxHCQaTnGLQA6f9jZvLEmbMj6Zw@mail.gmail.com>
Date: Mon, 1 Jun 2015 15:02:12 -0400
Message-ID: <CABHVRKSm08T7ik4Ozd-WgMTrkT2c0waKDwg6Ma+ZMTWWeevfAw@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Jim Phillips <jim@ergophobia.org>
Content-Type: multipart/alternative; boundary=001a11395e8ea31ad205177976bd
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(stephencalebmorse[at]gmail.com)
-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
0.0 T_REMOTE_IMAGE Message contains an external image
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YzUyY-0002DI-0E
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?
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: Mon, 01 Jun 2015 19:02:20 -0000
--001a11395e8ea31ad205177976bd
Content-Type: text/plain; charset=UTF-8
This exact question came up on the Bitcoin Stack Exchange once. I gave an
answer here:
http://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maximum-block-size/37303#37303
On Mon, Jun 1, 2015 at 2:32 PM, Jim Phillips <jim@ergophobia.org> wrote:
> Ok, I understand at least some of the reason that blocks have to be kept
> to a certain size. I get that blocks which are too big will be hard to
> propagate by relays. Miners will have more trouble uploading the large
> blocks to the network once they've found a hash. We need block size
> constraints to create a fee economy for the miners.
>
> But these all sound to me like issues that affect some, but not others. So
> it seems to me like it ought to be a configurable setting. We've already
> witnessed with last week's stress test that most miners aren't even
> creating 1MB blocks but are still using the software defaults of 730k. If
> there are configurable limits, why does there have to be a hard limit?
> Can't miners just use the configurable limit to decide what size blocks
> they can afford to and are thus willing to create? They could just as
> easily use that to create a fee economy. If the miners with the most
> hashpower are not willing to mine blocks larger than 1 or 2 megs, then they
> are able to slow down confirmations of transactions. It may take several
> blocks before a miner willing to include a particular transaction finds a
> block. This would actually force miners to compete with each other and find
> a block size naturally instead of having it forced on them by the protocol.
> Relays would be able to participate in that process by restricting the
> miners ability to propagate large blocks. You know, like what happens in a
> FREE MARKET economy, without burdensome regulation which can be manipulated
> through politics? Isn't that what's really happening right now? Different
> political factions with different agendas are fighting over how best to
> regulate the Bitcoin protocol.
>
> I know the limit was originally put in place to prevent spamming. But that
> was when we were mining with CPUs and just beginning to see the occasional
> GPU which could take control over the network and maliciously spam large
> blocks. But with ASIC mining now catching up to Moore's Law, that's not
> really an issue anymore. No one malicious entity can really just take over
> the network now without spending more money than it's worth -- and that's
> just going to get truer with time as hashpower continues to grow. And it's
> not like the hard limit really does anything anymore to prevent spamming.
> If a spammer wants to create thousands or millions of transactions, a hard
> limit on the block size isn't going to stop him.. He'll just fill up the
> mempool or UTXO database instead of someone's block database.. And block
> storage media is generally the cheapest storage.. I mean they could be
> written to tape and be just as valid as if they're stored in DRAM. Combine
> that with pruning, and block storage costs are almost a non-issue for
> anyone who isn't running an archival node.
>
> And can't relay nodes just configure a limit on the size of blocks they
> will relay? Sure they'd still need to download a big block occasionally,
> but that's not really that big a deal, and they're under no obligation to
> propagate it.. Even if it's a 2GB block, it'll get downloaded eventually.
> It's only if it gets to the point where the average home connection is too
> slow to keep up with the transaction & block flow that there's any real
> issue there, and that would happen regardless of how big the blocks are. I
> personally would much prefer to see hardware limits act as the bottleneck
> than to introduce an artificial bottleneck into the protocol that has to be
> adjusted regularly. The software and protocol are TECHNICALLY capable of
> scaling to handle the world's entire transaction set. The real issue with
> scaling to this size is limitations on hardware, which are regulated by
> Moore's Law. Why do we need arbitrary soft limits? Why can't we allow
> Bitcoin to grow naturally within the ever increasing limits of our
> hardware? Is it because nobody will ever need more than 640k of RAM?
>
> Am I missing something here? Is there some big reason that I'm overlooking
> why there has to be some hard-coded limit on the block size that affects
> the entire network and creates ongoing issues in the future?
>
> --
>
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy*
>
> *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a11395e8ea31ad205177976bd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This exact question came up on the Bitcoin Stack Exchange =
once. I gave an answer here:=C2=A0<a href=3D"http://bitcoin.stackexchange.c=
om/questions/37292/whats-the-purpose-of-a-maximum-block-size/37303#37303">h=
ttp://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maxi=
mum-block-size/37303#37303</a></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Mon, Jun 1, 2015 at 2:32 PM, Jim Phillips <span dir=
=3D"ltr"><<a href=3D"mailto:jim@ergophobia.org" target=3D"_blank">jim@er=
gophobia.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Ok, I understand at least some of the reason that blocks have to=
be kept to a certain size. I get that blocks which are too big will be har=
d to propagate by relays. Miners will have more trouble uploading the large=
blocks to the network once they've found a hash. We need block size co=
nstraints to create a fee economy for the miners.<div><br>But these all sou=
nd to me like issues that affect some, but not others. So it seems to me li=
ke it ought to be a configurable setting. We've already witnessed with =
last week's stress test that most miners aren't even creating 1MB b=
locks but are still using the software defaults of 730k. If there are confi=
gurable limits, why does there have to be a hard limit? Can't miners ju=
st use the configurable limit to decide what size blocks they can afford to=
and are thus willing to create? They could just as easily use that to crea=
te a fee economy. If the miners with the most hashpower are not willing to =
mine blocks larger than 1 or 2 megs, then they are able to slow down confir=
mations of transactions. It may take several blocks before a miner willing =
to include a particular transaction finds a block. This would actually forc=
e miners to compete with each other and find a block size naturally instead=
of having it forced on them by the protocol. Relays would be able to parti=
cipate in that process by restricting the miners ability to propagate large=
blocks. You know, like what happens in a FREE MARKET=C2=A0economy, without=
burdensome regulation which can be manipulated through politics? Isn't=
that what's really happening right now? Different political factions w=
ith different agendas are fighting over how best to regulate the Bitcoin pr=
otocol.<br><br></div><div>I know the limit was originally put in place to p=
revent spamming. But that was when we were mining with CPUs and just beginn=
ing to see the occasional GPU which could take control over the network and=
maliciously spam large blocks. But with ASIC mining now catching up to Moo=
re's Law, that's not really an issue anymore. No one malicious enti=
ty can really just take over the network now without spending more money th=
an it's worth -- and that's just going to get truer with time as ha=
shpower continues to grow. And it's not like the hard limit really does=
anything anymore to prevent spamming. If a spammer wants to create thousan=
ds or millions of transactions, a hard limit on the block size isn't go=
ing to stop him.. He'll just fill up the mempool or UTXO database inste=
ad of someone's block database.. And block storage media is generally t=
he cheapest storage.. I mean they could be written to tape and be just as v=
alid as if they're stored in DRAM. Combine that with pruning, and block=
storage costs are almost a non-issue for anyone who isn't running an a=
rchival node.</div><div><br>And can't relay nodes just configure a limi=
t on the size of blocks they will relay? Sure they'd still need to down=
load a big block occasionally, but that's not really that big a deal, a=
nd they're under no obligation to propagate it.. Even if it's a 2GB=
block, it'll get downloaded eventually. It's only if it gets to th=
e point where the average home connection is too slow to keep up with the t=
ransaction & block flow that there's any real issue there, and that=
would happen regardless of how big the blocks are. I personally would much=
prefer to see hardware limits act as the bottleneck than to introduce an a=
rtificial bottleneck into the protocol that has to be adjusted regularly.=
=C2=A0The software and protocol are TECHNICALLY capable of scaling to handl=
e the world's entire transaction set. The real issue with scaling to th=
is size is limitations on hardware, which are regulated by Moore's Law.=
Why do we need arbitrary soft limits? Why can't we allow Bitcoin to gr=
ow naturally within the ever increasing limits of our hardware? Is it becau=
se nobody will ever need more than 640k of RAM?<br><br></div><div>Am I miss=
ing something here? Is there some big reason that I'm overlooking why t=
here has to be some hard-coded limit on the block size that affects the ent=
ire network and creates ongoing issues in the future?</div><div><br><div><d=
iv><div>--</div><div><br><div><b>James G. Phillips IV</b>=C2=A0<a href=3D"h=
ttps://plus.google.com/u/0/113107039501292625391/posts" style=3D"font-size:=
x-small" target=3D"_blank"><img src=3D"https://ssl.gstatic.com/images/icons=
/gplus-16.png"></a></div></div><div><font size=3D"1"><i>"Don't bun=
t. Aim out of the ball park. Aim for the company of immortals." -- Dav=
id Ogilvy<br></i></font><div><font size=3D"1"><br></font></div></div><div><=
font size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fugue/16/=
leaf.png">=C2=A0<em style=3D"font-family:verdana,geneva,sans-serif;line-hei=
ght:16px;color:green;background-color:rgb(255,255,255)">This message was cr=
eated with 100% recycled electrons. Please think twice before printing.</em=
></font></div></div></div>
</div></div>
<br>-----------------------------------------------------------------------=
-------<br>
<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></div>
--001a11395e8ea31ad205177976bd--
|
