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
|
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
|
