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
|
Return-Path: <sean@seangreenslade.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9F30CD82
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Feb 2016 06:29:57 +0000 (UTC)
X-Greylist: delayed 00:09:48 by SQLgrey-1.7.6
Received: from cartman.routify.me (email.routify.me [162.208.10.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 33768115
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Feb 2016 06:29:57 +0000 (UTC)
Received: from wheatley.student.rit.edu (wheatley.student.rit.edu
[129.21.63.175])
by cartman.routify.me (Postfix) with ESMTPSA id 55D3C80E34;
Sat, 13 Feb 2016 01:20:08 -0500 (EST)
Date: Sat, 13 Feb 2016 01:20:06 -0500
From: Sean Greenslade <sean@seangreenslade.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20160213062005.GC7436@wheatley.student.rit.edu>
References: <56BA71D4.5040200@riseup.net> <56BBA879.5030309@riseup.net>
<60215.178.73.210.16.1455174198.squirrel@boosthardware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <60215.178.73.210.16.1455174198.squirrel@boosthardware.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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: Sat, 13 Feb 2016 08:13:14 +0000
Subject: Re: [bitcoin-dev] Clearing up some misconceptions about full nodes
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: Sat, 13 Feb 2016 06:29:57 -0000
On Thu, Feb 11, 2016 at 06:03:18PM +1100, Patrick Shirkey via bitcoin-dev wrote:
> This is very useful information but from my experience it is not viable to
> have a full node running full time on a desktop system i.e sharing the
> system with a normal desktop workload.
>
> With a very powerful "Desktop" machine bitcoin-qt dominates CPU/GPU
> resources. Surely the majority of nodes NOT running open ports are being
> run on desktop systems. It's likely that the vast majority of the
> "normal/desktop" user base are not going to setup dedicated machines to
> run a full node full time.
I suspect you may be confusing full nodes with mining nodes. The two are
not directly synonymous. When running a full node in non-mining mode,
the CPU load is fairly light and the GPU is not touched at all. There is
a decent amount of RAM / disk used, but I've found that running a full
node on my low-power NAS box to be a nice way to use the extra idle CPU
time in a somewhat useful way (again, not mining). I've also run a full
node on a netbook without any trouble.
> It's likely that the vast majority of full nodes that are not running open
> ports are used occasionally when the user wants to make a transaction or
> "catch up" with the blockchain.
>
> That creates a divide between those who do have the resources to
> contribute to the system on a full time basis (minority) and those who do
> not (majority).
Bitcoin is extremely tolerant of nodes entering and leaving the network
at will. Even part time nodes help to improve the quality of the network
purely by following the rules when passing on blocks / transactions
(i.e. preventing the propogation of erroneous or invalid data and
checking the proof of work of all present chains)
> Does the power of p2p decentralization lie with the vast majority or the
> "wealthy" resource rich minority?
>
> How will the move to 2MB hard fork affect the vast majority of nodes?
They will need to upgrade, so yes it will affect every node.
> The rollout affect of the hard fork on the entire bitcoin ecosystem is a
> difficult process to plan in advance. It's not viable to simply rely on
> press releases to encourage users to upgrade their nodes. The debacle with
> Pulse Audio during the mid 2000's should be a lesson for those who seek
> that route.
This has been thoroughly discussed in other threads. Hard forks are not
done on a whim.
--Sean
|
