diff options
author | Patrick Shirkey <pshirkey@boosthardware.com> | 2016-02-10 17:36:05 +1100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2016-02-10 07:01:47 +0000 |
commit | 099fb539f69e84784ba3110bd589711e16e01e53 (patch) | |
tree | b98b4d50018eeecba259ff7a230bf7a5f7d087ee | |
parent | b44283df824a18457f968f591730ed4e6aee3447 (diff) | |
download | pi-bitcoindev-099fb539f69e84784ba3110bd589711e16e01e53.tar.gz pi-bitcoindev-099fb539f69e84784ba3110bd589711e16e01e53.zip |
Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
-rw-r--r-- | 90/49d21b366e22555b3db00affe6913854d6b4b7 | 127 |
1 files changed, 127 insertions, 0 deletions
diff --git a/90/49d21b366e22555b3db00affe6913854d6b4b7 b/90/49d21b366e22555b3db00affe6913854d6b4b7 new file mode 100644 index 000000000..1616b7794 --- /dev/null +++ b/90/49d21b366e22555b3db00affe6913854d6b4b7 @@ -0,0 +1,127 @@ +Return-Path: <pshirkey@boosthardware.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 34776DBA + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 10 Feb 2016 07:01:47 +0000 (UTC) +X-Greylist: delayed 00:25:38 by SQLgrey-1.7.6 +Received: from boosthardware.localdomain (boosthardware.com [88.198.122.139]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 555F0106 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 10 Feb 2016 07:01:46 +0000 (UTC) +Received: by boosthardware.localdomain (Postfix, from userid 48) + id 732024002D; Wed, 10 Feb 2016 07:36:05 +0100 (CET) +Received: from 178.73.210.16 + (SquirrelMail authenticated user pshirkey@boosthardware.com) + by boosthardware.com with HTTP; Wed, 10 Feb 2016 17:36:05 +1100 (EST) +Message-ID: <56188.178.73.210.16.1455086165.squirrel@boosthardware.com> +In-Reply-To: <CAFVRnyq7xADJz9nfH05izyfLvGuB_+z=AAXkFFrao6DqKsSTWQ@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> + <CABsx9T2ewNQn7sxc675Qz6KNF-6DfZjYBY6Q2b6GTZ42X2piwQ@mail.gmail.com> + <CAFVRnyq7xADJz9nfH05izyfLvGuB_+z=AAXkFFrao6DqKsSTWQ@mail.gmail.com> +Date: Wed, 10 Feb 2016 17:36:05 +1100 (EST) +From: "Patrick Shirkey" <pshirkey@boosthardware.com> +To: "Bitcoin Dev" <bitcoin-dev@lists.linuxfoundation.org> +User-Agent: SquirrelMail/1.4.8-5.el5.centos.10 +MIME-Version: 1.0 +Content-Type: text/plain;charset=iso-8859-1 +Content-Transfer-Encoding: 8bit +X-Priority: 3 (Normal) +Importance: Normal +X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD + 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 12:02:14 +0000 +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: Wed, 10 Feb 2016 07:01:47 -0000 + + +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 + |