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
|
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 E0D48E78
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Feb 2016 16:54:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com
[209.85.217.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B503018D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Feb 2016 16:54:16 +0000 (UTC)
Received: by mail-lb0-f174.google.com with SMTP id dx2so103821230lbd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 09 Feb 2016 08:54:16 -0800 (PST)
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=MMyBtYTOOjWhkYLpvwv6qP5rT1BQzxyEmNkXxIIc6qo=;
b=xgU2IV41ZLwP0UAPCyBe1tIINqiuxtKdDluLQ6Op2oRkWA+vQfayu3IrzcweirBsKw
dV0Dsc0wxCq7Xvw5SrLaEO051QEeCUFAta0BDIKivghgUyiYFS7l984wirJHJg0UArvG
iDgVDNfZxapRrtcLInY/T5Hiw6+4CcPkCSKZ0Ta49gnnqqBDA+/MblqnoAIkxmijBhty
7oGuG5u+iVhcguR0FcHk1zDlN3Zh6npOHwnh/8Q19IR16ZAQEAj5IwUvfSdRjr2xGyQZ
0yoqnTIKzX+Wx3WisMPbKp6pO4taDdZbBWicZ2avT1/NJ2u+UGZpyKaOLB1unfEIQ3Do
RmCw==
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=MMyBtYTOOjWhkYLpvwv6qP5rT1BQzxyEmNkXxIIc6qo=;
b=JrAM0wH21fTkQ/yNsvOSxMJrrm4Vn16Evew51IurlnwNepSbUfjPN53s9/t68nKfqi
Q0cgRIxujJAmWn99iD5Db/QJkoRZ9pVQ3hSPX519VFfIC1zHx5XrfzoIt9vnFb/zCCLQ
bsPzDm3eKwfP9zOkuQyv4CnxLplXf00KQAz1UigyxIVLlFQAw/yrXsi3y0AvHg0RqSFF
hYrPtLor7YeIjg7h6a4KK7Pfm8N7nSZClqN50HuNKdcYNuuROSgAVo+eiyE74YVGybtD
ihKQ13q0ePuze2jTf1kLWpVKkx+r/nSTC71XBmAcKZtaRJ5P+P0gM8yhatHT9SaaOlWA
DAAg==
X-Gm-Message-State: AG10YORneUefJKM01X56GakNICKRRXCYsnCpm6XMuUO+zScQ8U3mCnFH5wCNdsS5Vs4IInH0E189nwkP3E7Kgw==
MIME-Version: 1.0
X-Received: by 10.112.171.134 with SMTP id au6mr9804622lbc.27.1455036854990;
Tue, 09 Feb 2016 08:54:14 -0800 (PST)
Received: by 10.25.206.68 with HTTP; Tue, 9 Feb 2016 08:54:14 -0800 (PST)
In-Reply-To: <CAHcfU-W9vubmuRFSb-zZgdKdCvXdO9ttZtu9T2tNxWTHcsGaTA@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
<201602060012.26728.luke@dashjr.org>
<CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
<CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
<CAHcfU-W9vubmuRFSb-zZgdKdCvXdO9ttZtu9T2tNxWTHcsGaTA@mail.gmail.com>
Date: Tue, 9 Feb 2016 11:54:14 -0500
Message-ID: <CABsx9T2ewNQn7sxc675Qz6KNF-6DfZjYBY6Q2b6GTZ42X2piwQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Yifu Guo <yifu@coinapex.com>
Content-Type: multipart/alternative; boundary=001a11c376dce0837c052b592aaa
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW, URIBL_SBL autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 10 Feb 2016 05:26:27 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes
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, 09 Feb 2016 16:54:18 -0000
--001a11c376dce0837c052b592aaa
Content-Type: text/plain; charset=UTF-8
On Tue, Feb 9, 2016 at 8:59 AM, Yifu Guo <yifu@coinapex.com> wrote:
>
> There are 406 nodes total that falls under the un-maintained category,
> which is below 10% of the network.
> Luke also have some data here that shows similar results.
> http://luke.dashjr.org/programs/bitcoin/files/charts/versions.txt
>
I love seeing data! I was considering 0.10 nodes as 'unmaintained' because
it has been a long time since the 0.11 release.
>
> > The network could shrink by 60% and it would still have plenty of open
>> connection slots
>
>
> I'm afraid we have to agree to disagree if you think dropping support for
> 60% of the nodes on the network when rolling out an upgrade is the sane
> default.
>
That is my estimate of the worst-case-- not 'sane default.'
My point is that even if the number of nodes shrank by 60%, we would not
see any issues (SPV nodes would still have no problem finding a full node
to connect to, full nodes would not have any problem connecting to each
other, and we would not be significantly more vulnerable to Sybil attacks
or "governments get together and try to ban running a full node" attacks).
>
>> > People are committing to spinning up thousands of supports-2mb-nodes
>> during the grace period.
>
>
> thousands of nodes?! where did you get this figure? who are these people?
> *Please* elaborate.
>
There are over a thousand people subscribed to the Classic slack channel,
many of whom have privately told me they are willing and able to run an
extra node or three (or a hundred-and-eleven) once there is a final release.
I'm not going to name names, because
a) these were private communications, and
b) risk of death threats, extortion, doxxing, DoS attacks, etc. Those
risks aren't theoretical, they are very real.
To be clear: I will discourage and publicly condemn anybody who runs
'pseudo nodes' or plans to spin up lots of nodes to try to influence the
debate. The only legitimate reason to run extra nodes is to fill in a
possible gap in total node count that might be caused by old, unmaintained
nodes that stop serving blocks because the rest of the network has upgraded.
> We could wait a year and pick up maybe 10 or 20% more.
>
>
> I don't understand this statement at all, please explicate.
>
The adoption curve for a new major release is exponential: lots of adoption
in the first 30 days or so, then it rapidly tapers off. Given that
people's nodes will be alerting them that they must upgrade, and given that
every source of Bitcoin news will probably be covering the miner adoption
vote like it was a presidential election, I expect the adoption curve for
the 2mb bump to be steeper than we've ever seen. So my best guess is
70-80% of nodes will upgrade within 30 days of the miner voting hitting 50%
of blocks and triggering the automatic 'version obsolete; upgrade required'
warning.
Wait a year, and my guess is you might reach another 10-20% (80 to
90-something percent).
--001a11c376dce0837c052b592aaa
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, Feb 9, 2016 at 8:59 AM, Yifu Guo <span dir=3D"ltr"><<a href=3D"mailt=
o:yifu@coinapex.com" target=3D"_blank">yifu@coinapex.com</a>></span> wro=
te:<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"><div><div><div><br><=
/div><div>There are 406 nodes total that falls under the un-maintained cate=
gory, which is below 10% of the network.</div><div>Luke also have some data=
here that shows similar results.=C2=A0<a href=3D"http://luke.dashjr.org/pr=
ograms/bitcoin/files/charts/versions.txt" target=3D"_blank">http://luke.das=
hjr.org/programs/bitcoin/files/charts/versions.txt</a></div></div></div></d=
iv></blockquote><div><br></div><div>I love seeing data!=C2=A0 I was conside=
ring 0.10 nodes as 'unmaintained' because it has been a long time s=
ince the 0.11 release.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div><span class=3D""><div><br></div><blockquote cla=
ss=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;padding-left:1ex=
">> The network could shrink by 60% and it would still have plenty of op=
en connection slots</blockquote><div><br></div></span><div>I'm afraid w=
e have to agree to disagree if you think dropping support for 60% of the no=
des on the network when rolling out an upgrade is the sane default.</div></=
div></div></div></blockquote><div><br></div><div>That is my estimate of the=
worst-case-- not 'sane default.'</div><div><br></div><div>My point=
is that even if the number of nodes shrank by 60%, we would not see any is=
sues (SPV nodes would still have no problem finding a full node to connect =
to, full nodes would not have any problem connecting to each other, and we =
would not be significantly more vulnerable to Sybil attacks or "govern=
ments get together and try to ban running a full node" attacks).</div>=
<div><br></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"><div dir=3D"=
ltr"><div><div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><br>> People are commit=
ting to spinning up thousands of supports-2mb-nodes during the grace period=
.</blockquote><div><br></div></span><div>thousands of nodes?! where did you=
get this figure? who are these people? <i><b>Please</b></i> elaborate.</di=
v></div></div></div></blockquote><div><br></div><div>There are over a thous=
and people subscribed to the Classic slack channel, many of whom have priva=
tely told me they are willing and able to run an extra node or three (or a =
hundred-and-eleven) once there is a final release.</div><div><br></div><div=
>I'm not going to name names, because</div><div>=C2=A0a) these were pri=
vate communications, and</div><div>=C2=A0b) risk of death threats, extortio=
n, doxxing, DoS attacks, etc.=C2=A0 Those risks aren't theoretical, the=
y are very real.</div><div><br></div><div>To be clear: I will discourage an=
d publicly condemn anybody who runs 'pseudo nodes' or plans to spin=
up lots of nodes to try to influence the debate. The only legitimate reaso=
n to run extra nodes is to fill in a possible gap in total node count that =
might be caused by old, unmaintained nodes that stop serving blocks because=
the rest of the network has upgraded.</div><div><br></div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span class=3D""><div><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex">> We could wait a year and pick up maybe 10 or 20%=
more.</blockquote></span></div><div><br></div><div>I don't understand =
this statement at all, please=C2=A0explicate.</div></div></blockquote><div>=
<br></div><div>The adoption curve for a new major release is exponential: l=
ots of adoption in the first 30 days or so, then it rapidly tapers off.=C2=
=A0 Given that people's nodes will be alerting them that they must upgr=
ade, and given that every source of Bitcoin news will probably be covering =
the miner adoption vote like it was a presidential election, I expect the a=
doption curve for the 2mb bump to be steeper than we've ever seen.=C2=
=A0 So my best guess is 70-80% of nodes will upgrade within 30 days of the =
miner voting hitting 50% of blocks and triggering the automatic 'versio=
n obsolete; upgrade required' warning.</div><div><br></div><div>Wait a =
year, and my guess is you might reach another 10-20% (80 to 90-something pe=
rcent).</div><div><br></div></div>
</div></div>
--001a11c376dce0837c052b592aaa--
|
