summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPatrick Shirkey <pshirkey@boosthardware.com>2016-02-10 17:36:05 +1100
committerbitcoindev <bitcoindev@gnusha.org>2016-02-10 07:01:47 +0000
commit099fb539f69e84784ba3110bd589711e16e01e53 (patch)
treeb98b4d50018eeecba259ff7a230bf7a5f7d087ee
parentb44283df824a18457f968f591730ed4e6aee3447 (diff)
downloadpi-bitcoindev-099fb539f69e84784ba3110bd589711e16e01e53.tar.gz
pi-bitcoindev-099fb539f69e84784ba3110bd589711e16e01e53.zip
Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
-rw-r--r--90/49d21b366e22555b3db00affe6913854d6b4b7127
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
+