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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DFCCEAC1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 20:12:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com
[209.85.215.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8EDBD1AF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 20:12:19 +0000 (UTC)
Received: by lagx9 with SMTP id x9so13640068lag.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 13:12:17 -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=3kvh2FnB0znB/RjuiAvJba2UVYx3mNsKRG1aaloS20E=;
b=Y8rJG7VJiXPzBDd7IomUmDvtap9VlMXd3bL4RxcH0W4l/00bo6lI5C0WP9w1i20Qe4
ZzK4b4cqDTbdrb0RBlykewL2UiNZ0SkwwAQ+OXOZT24hu2jBQzKZUFTqWt+iKp+CCYx1
WkHTLoQsb3joKYczqB69sKIUW85ApEwHTqARG3/xiO6+rlwr43zddWKaOqJmHMFBlyX3
mqGjiUi5sSDMzFwwJ88jl6pAxIW4vUqaLExuOsZqRuKacUoV7pEq7Yv798QWasTvk8SN
b/KZ5ghQUr8lYkUSZxU7e82gr0N+OSpjOq2/7rNr/oG/YGZ85MdpvnOQ20HUlL9b5aMa
2Q+g==
MIME-Version: 1.0
X-Received: by 10.112.147.201 with SMTP id tm9mr1565824lbb.40.1435090337603;
Tue, 23 Jun 2015 13:12:17 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Tue, 23 Jun 2015 13:12:17 -0700 (PDT)
In-Reply-To: <20150623192838.GG30235@muck>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
<20150623192838.GG30235@muck>
Date: Tue, 23 Jun 2015 16:12:17 -0400
Message-ID: <CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7b34391acb25c705193501cb
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
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, 23 Jun 2015 20:12:21 -0000
--047d7b34391acb25c705193501cb
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete@petertodd.org> wrote:
> On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
> > ==Rationale==
> >
> > The initial size of 8,000,000 bytes was chosen after testing the current
> > reference implementation code with larger block sizes and receiving
> > feedback from miners stuck behind bandwidth-constrained networks (in
> > particular, Chinese miners behind the Great Firewall of China).
> >
> > The doubling interval was chosen based on long-term growth trends for CPU
> > power, storage, and Internet bandwidth. The 20-year limit was chosen
> > because exponential growth cannot continue forever.
>
> Wladimir noted that 'The original presented intention of block size
> increase was a one-time "scaling" to grant time for more decentralizing
> solutions to develop'
>
> Comments?
>
Consensus is that this process is too painful to go through once a year. I
agree.
If you disagree and would like to see a Blocksize Council meet once a year
to issue a decree on what the maximum block size shall be for the next
year, then propose a process for who gets to sit on the Council and how
their decrees are enforced.....
>
> In particular, if bandwidth scaling doesn't go according to your plan,
> e.g. the exponential exponent is too large, perhaps due to technological
> growth not keeping pace, or the political realities of actual bandwidth
> deployment making theoretical technological growth irrelevant, what
> mechanism will prevent centralization? (if any)
Simulations show that:
Latency/bandwidth matter for miners. Low latency, high bandwidth is
better. However, miners with bad connectivity can simply create smaller
blocks...
... until transaction fees become significant. But by the time that
happens, protocol optimizations of block propagation will make the block
size an insignificant term in the "how profitable is it to mine in THIS
particular place on the Internet / part of the world" equation.
(Reference:
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08224.html
)
So: for the immediate future, there is no problem. And in the long term,
there is no problem.
--
--
Gavin Andresen
--047d7b34391acb25c705193501cb
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, Jun 23, 2015 at 3:28 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></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);border-left-s=
tyle:solid;padding-left:1ex"><span class=3D"">On Mon, Jun 22, 2015 at 02:18=
:19PM -0400, Gavin Andresen wrote:<br>
</span><span class=3D"">> =3D=3DRationale=3D=3D<br>
><br>
> The initial size of 8,000,000 bytes was chosen after testing the curre=
nt<br>
> reference implementation code with larger block sizes and receiving<br=
>
> feedback from miners stuck behind bandwidth-constrained networks (in<b=
r>
> particular, Chinese miners behind the Great Firewall of China).<br>
><br>
> The doubling interval was chosen based on long-term growth trends for =
CPU<br>
> power, storage, and Internet bandwidth. The 20-year limit was chosen<b=
r>
> because exponential growth cannot continue forever.<br>
<br>
</span>Wladimir noted that 'The original presented intention of block s=
ize<br>
increase was a one-time "scaling" to grant time for more decentra=
lizing<br>
solutions to develop'<br>
<br>
Comments?<br></blockquote><div><br></div><div>Consensus is that this proces=
s is too painful to go through once a year.=C2=A0 I agree.</div><div><br></=
div><div>If you disagree and would like to see a Blocksize Council meet onc=
e a year to issue a decree on what the maximum block size shall be for the =
next year, then propose a process for who gets to sit on the Council and ho=
w their decrees are enforced.....</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
In particular, if bandwidth scaling doesn't go according to your plan,<=
br>
e.g. the exponential exponent is too large, perhaps due to technological<br=
>
growth not keeping pace, or the political realities of actual bandwidth<br>
deployment making theoretical technological growth irrelevant, what<br>
mechanism will prevent centralization? (if any)</blockquote></div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Simulations show tha=
t:</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Lat=
ency/bandwidth matter for miners.=C2=A0 Low latency, high bandwidth is bett=
er. However, miners with bad connectivity can simply create smaller blocks.=
..</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">...=
until transaction fees become significant.=C2=A0 But by the time that happ=
ens, protocol optimizations of block propagation will make the block size a=
n insignificant term in the "how profitable is it to mine in THIS part=
icular place on the Internet / part of the world" equation.=C2=A0</div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">(Reference=
:=C2=A0<a href=3D"https://www.mail-archive.com/bitcoin-development@lists.so=
urceforge.net/msg08224.html">https://www.mail-archive.com/bitcoin-developme=
nt@lists.sourceforge.net/msg08224.html</a> )</div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">So: for the immediate future, there =
is no problem. And in the long term, there is no problem.</div><div class=
=3D"gmail_extra"><br></div>-- <br><div class=3D"gmail_signature">--<br>Gavi=
n Andresen<br></div>
</div></div>
--047d7b34391acb25c705193501cb--
|
