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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1Yyqsj-00025L-LH
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 00:13:37 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.43 as permitted sender)
client-ip=74.125.82.43; envelope-from=alex.mizrahi@gmail.com;
helo=mail-wg0-f43.google.com;
Received: from mail-wg0-f43.google.com ([74.125.82.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yyqsi-0002Vx-DE
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 00:13:37 +0000
Received: by wgv5 with SMTP id 5so88221702wgv.1
for <bitcoin-development@lists.sourceforge.net>;
Sat, 30 May 2015 17:13:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.208.7 with SMTP id ma7mr8381737wic.0.1433031210453; Sat,
30 May 2015 17:13:30 -0700 (PDT)
Received: by 10.27.102.73 with HTTP; Sat, 30 May 2015 17:13:30 -0700 (PDT)
In-Reply-To: <44570322-FBAE-4BAF-A0DA-2E478EF436B4@gmail.com>
References: <554BE0E1.5030001@bluematt.me>
<CAFzgq-xByQ1E_33_m3UpXQFUkGc78HKnA=7XXMshANDuTkNsvA@mail.gmail.com>
<CABsx9T0kbRe31LMwk499MQUw225f5GGd67GfhXBezHmDqxkioA@mail.gmail.com>
<CAE28kUTSgrU0kY6zLHrZXAAP+XD2H=NqT8rE3jt6Cp+1qGkHRg@mail.gmail.com>
<44570322-FBAE-4BAF-A0DA-2E478EF436B4@gmail.com>
Date: Sun, 31 May 2015 03:13:30 +0300
Message-ID: <CAE28kUSe07r=Z4WtcsAQ211iO3W_fb_Na89UhhMOoX95ef-H1A@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c383ce40503f05175594c1
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
(alex.mizrahi[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
X-Headers-End: 1Yyqsi-0002Vx-DE
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: Sun, 31 May 2015 00:13:37 -0000
--001a11c383ce40503f05175594c1
Content-Type: text/plain; charset=UTF-8
> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
>
> Do you anticipate linear growth?
>
It's safe to say that absolutely nobody can predict the actual growth with
any degree of an accuracy.
I believe that linear growth compares very favorably to other alternatives:
1. Exponential growth: Linear growth is better at modelling diminishing
returns, that is, risk that it grows too much is much smaller. At the same
time initially it will grow faster than reasonable exponential models.
E.g. linear year-over-year relative growth: 100% 50% 33% 25% ...10%
While exponential one which gives the same result in 10 years:
25% 25% ... 25%
This is on the same scale, but exponential starts slower than we want at
start (1.25 MB will be too little for 2016 as we already see fully filled 1
MB blocks), but goes a bit too fast in the long term. It's highly unlikely
we'll see bandwidth growing 10x each 10 years in the long term.
2. Single step increase: an obvious advantage is that linear growth gives
us time to adapt to near realities, time to change something if there is an
unwanted effects, etc. At the same a single step is not a long-term
solution.
While a slow-but-steady growth might be.
3. Adaptive solutions (e.g. limit depends on the last N blocks or something
of that nature):
The problem with them is that they are rather complex, and also:
3.1. prone to manipulation: somebody might try to push the limit if it
will favor him in future
3.2. possibility of a positive feedback loop.
3.3. possibility of an unhealthy game-theoretic dynamics
The main problem is that we do not understand game theoretic aspects of
bitcoin mining in presence of various real-world factors such as block
propagation delays. Thus we can't design a proper adaptive solution.
There is no perfect solution to this problem as we cannot predict the
future and our understanding is limited.
But among the 5 alternatives (linear, exponential, single step, adaptive,
no limit), linear seems to be the best option at this point as it's both
quite safe and doesn't stunt growth too much.
> bitcoin is really really small right now, any sign of real adoption could
make it grow 100x or even more in a matter of weeks.
This is certainly possible, but the thing is:
1) this can't be predicted;
2) this will be a serious problem for many bitcoind installations;
3) it's not necessarily a healthy thing, perhaps it will grow 100x in a
matter of weeks, and then will go to zero in matter of weeks as well.
So I don't think that sudden growth spurts is something we should take into
account on the planning stage. If anything we'd like to prevent them from
happening, slow growth is usually better.
--001a11c383ce40503f05175594c1
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"><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-style:solid;p=
adding-left:1ex"><div dir=3D"auto"><span class=3D""><div><blockquote type=
=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><font color=3D"#000000"><span style=3D"background-color:rgba(255,255,=
255,0)">Why 20 MB? Do you anticipate 20x transaction count growth in 2016?<=
/span></font></div></div></div></blockquote></div></span><div>Do you antici=
pate linear growth?</div></div></blockquote><div><br></div><div>It's sa=
fe to say that absolutely nobody can predict the actual growth with any deg=
ree of an accuracy.</div><div>I believe that linear growth compares very fa=
vorably to other alternatives:</div><div><br></div><div>1. Exponential grow=
th: Linear growth is better at modelling diminishing returns, that is, risk=
that it grows too much is much smaller. At the same time initially it will=
grow faster than reasonable exponential models.</div><div>=C2=A0 =C2=A0E.g=
. linear year-over-year relative growth: =C2=A0 =C2=A0100% 50% 33% 25% ...1=
0%</div><div>=C2=A0 =C2=A0While exponential one which gives the same result=
in 10 years:</div><div>=C2=A0 =C2=A025% 25% ... 25%</div><div>=C2=A0 =C2=
=A0This is on the same scale, but exponential starts slower than we want at=
start (1.25 MB will be too little for 2016 as we already see fully filled =
1 MB blocks), but goes a bit too fast in the long term. It's highly unl=
ikely we'll see bandwidth growing 10x each 10 years in the long term.</=
div><div><br></div><div>2. Single step increase: an obvious advantage is th=
at linear growth gives us time to adapt to near realities, time to change s=
omething if there is an unwanted effects, etc. At the same a single step is=
not a long-term solution.</div><div>While a slow-but-steady growth might b=
e.</div><div><br></div><div>3. Adaptive solutions (e.g. limit depends on th=
e last N blocks or something of that nature):</div><div>=C2=A0 The problem =
with them is that they are =C2=A0rather complex, and also:</div><div>=C2=A0=
3.1. prone to manipulation: somebody might try to push the limit if it wil=
l favor him in future</div><div>=C2=A0 3.2. possibility of a positive feedb=
ack loop.</div><div>=C2=A0 3.3. possibility of an unhealthy game-theoretic =
dynamics</div><div><br></div><div>The main problem is that we do not unders=
tand game theoretic aspects of bitcoin mining in presence of various real-w=
orld factors such as block propagation delays. Thus we can't design a p=
roper adaptive solution.</div><div><br></div><div><br></div><div>There is n=
o perfect solution to this problem as we cannot predict the future and our =
understanding is limited.</div><div>But among the 5 alternatives (linear, e=
xponential, single step, adaptive, no limit), linear seems to be the best o=
ption at this point as it's both quite safe and doesn't stunt growt=
h too much.</div><div><br></div><div>>=C2=A0<span style=3D"font-size:12.=
7272720336914px">bitcoin is really really small right now, any sign of real=
adoption could make it grow 100x or even more in a matter of weeks.</span>=
</div><div><span style=3D"font-size:12.7272720336914px"><br></span></div><d=
iv>This is certainly possible, but the thing is:</div><div><br></div><div>1=
) this can't be predicted;</div><div>2) this will be a serious problem =
for many bitcoind installations;</div><div>3) it's not necessarily a he=
althy thing, perhaps it will grow 100x in a matter of weeks, and then will =
go to zero in matter of weeks as well.</div><div><br></div><div>So I don=
9;t think that sudden growth spurts is something we should take into accoun=
t on the planning stage. If anything we'd like to prevent them from hap=
pening, slow growth is usually better.</div></div></div></div>
--001a11c383ce40503f05175594c1--
|
