public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Patrick Shirkey" <pshirkey@boosthardware.com>
To: "Bitcoin Dev" <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
Date: Wed, 10 Feb 2016 17:36:05 +1100 (EST)	[thread overview]
Message-ID: <56188.178.73.210.16.1455086165.squirrel@boosthardware.com> (raw)
In-Reply-To: <CAFVRnyq7xADJz9nfH05izyfLvGuB_+z=AAXkFFrao6DqKsSTWQ@mail.gmail.com>


On Wed, February 10, 2016 5:14 pm, David Vorick via bitcoin-dev wrote:
>>  I love seeing data!  I was considering 0.10 nodes as 'unmaintained'
> because it has been a long time since the 0.11 release.
>
> https://packages.gentoo.org/packages/net-p2p/bitcoin-qt
>
> The Gentoo package manager still has 0.10.2 as the most recent stable
> version. Getting a later version of the software on a gentoo setup
> requires
> explicitly telling the package manger to grab a later version. I don't
> know
> what percent of nodes are Gentoo 0.10.2, but I think it's evidence that
> 0.10 should not be considered 'unmaintained'. People who update their
> software regularly will be running 0.10 on Gentoo.
>
>> 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 clear on the utility of more nodes. Perhaps there is significant
> concern about SPV nodes getting enough bandwidth or the network struggling
> from the load? Generally though, I believe that when people talk about the
> deteriorating full node count they are talking about a reduction in
> decentralization. Full nodes are a weak indicator of how likely something
> like a change in consensus rules is to get caught, or how many people you
> would need to open communication with / extort in order to be able to
> force
> rules upon the network. Having a person spin up multiple nodes doesn't
> address either of those concerns, which in my understanding is what most
> people care about. My personal concern is with the percentage of the
> economy that is dependent on trusting the full nodes they are connected
> to,
> and the overall integrity of that trust. (IE how likely is it that my SPV
> node is going to lie to me about whether or not I've received a payment).
>
> I will also point out that lots of people will promise things when they
> are
> seeking political change. I don't know what percentage of promised nodes
> would actually be spun up, but I'm guessing that it's going to be
> significantly less than 100%. I have similar fears for companies that
> claim
> they have tested their infrastructure for supporting 2MB blocks. Talk is
> cheap.
>

This is a good point. The rollout procedure needs to be fully tested
*before* any changes are enforced.

Has anyone provided conclusive results on system load demands with an
increase to 2MB? Extrapolating further to higher blocksizes will also be
useful to get an idea of the scope of the problem. If the system does jump
to 2MB it is unlikely that will be the ultimate limit so 4, 8, 16 etc...
should also be quantified.

We already hear of the high system load (energy/cost) requirements* for
nodes under the current blocksize which appears to have created a barrier
to entry for a lot of miners. If increasing to 2MB makes it even more
expensive in terms of hardware and energy costs to run a node that will
consolidate the nodes into the control of a few wealthy parties who can
afford to run the most powerful hardware. Conversely if the increase helps
the system and individual nodes run more efficiently then that would be a
big incentive for miners to upgrade.


* (these reports might be false/wrong/propaganda)



--
Patrick Shirkey
Boost Hardware Ltd


  reply	other threads:[~2016-02-10  7:01 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
2016-02-10  6:14           ` David Vorick
2016-02-10  6:36             ` Patrick Shirkey [this message]
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=56188.178.73.210.16.1455086165.squirrel@boosthardware.com \
    --to=pshirkey@boosthardware.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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