From: Gavin Andresen <gavinandresen@gmail.com>
To: Yifu Guo <yifu@coinapex.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
Date: Tue, 9 Feb 2016 11:54:14 -0500 [thread overview]
Message-ID: <CABsx9T2ewNQn7sxc675Qz6KNF-6DfZjYBY6Q2b6GTZ42X2piwQ@mail.gmail.com> (raw)
In-Reply-To: <CAHcfU-W9vubmuRFSb-zZgdKdCvXdO9ttZtu9T2tNxWTHcsGaTA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]
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).
[-- Attachment #2: Type: text/html, Size: 4899 bytes --]
next prev parent reply other threads:[~2016-02-09 16:54 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 20:51 [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes Gavin Andresen
2016-02-05 22:36 ` Yifu Guo
2016-02-07 17:09 ` Gavin Andresen
2016-02-05 23:04 ` Btc Drak
2016-02-06 0:12 ` Luke Dashjr
2016-02-06 3:14 ` Jorge Timón
2016-02-06 15:37 ` Gavin Andresen
2016-02-06 17:01 ` Adam Back
2016-02-06 17:45 ` Gavin Andresen
2016-02-06 21:11 ` Peter Todd
2016-02-06 21:24 ` Peter Todd
2016-02-09 5:11 ` Samson Mow
2016-02-06 21:28 ` David Thomson
2016-02-07 18:49 ` Chris Priest
2016-02-06 17:09 ` Jorge Timón
2016-02-06 17:25 ` Tom Zander
2016-02-06 20:22 ` Chris Priest
2016-02-06 20:46 ` Luke Dashjr
2016-02-07 14:16 ` Gavin Andresen
2016-02-07 15:06 ` Alex Morcos
2016-02-07 16:54 ` Peter Todd
2016-02-07 15:19 ` Anthony Towns
2016-02-07 17:10 ` Jonathan Toomim
2016-02-07 17:24 ` jl2012
2016-02-07 17:56 ` Jonathan Toomim
2016-02-07 21:01 ` Luke Dashjr
2016-02-07 21:33 ` Steven Pine
2016-02-07 22:04 ` Corey Haddad
2016-02-07 22:25 ` Steven Pine
2016-02-06 20:36 ` Luke Dashjr
2016-02-06 22:22 ` Peter Todd
2016-02-07 5:21 ` Jannes Faber
2016-02-07 18:55 ` Jonathan Toomim
2016-02-07 19:03 ` Patrick Strateman
2016-02-07 19:19 ` Trevin Hofmann
2016-02-07 20:29 ` Tier Nolan
2016-02-09 13:59 ` Yifu Guo
2016-02-09 16:54 ` Gavin Andresen [this message]
2016-02-10 6:14 ` David Vorick
2016-02-10 6:36 ` Patrick Shirkey
2016-02-10 12:58 ` Tier Nolan
2016-02-07 11:37 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABsx9T2ewNQn7sxc675Qz6KNF-6DfZjYBY6Q2b6GTZ42X2piwQ@mail.gmail.com \
--to=gavinandresen@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=yifu@coinapex.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox