From: Sean Greenslade <sean@seangreenslade•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Clearing up some misconceptions about full nodes
Date: Sat, 13 Feb 2016 01:20:06 -0500 [thread overview]
Message-ID: <20160213062005.GC7436@wheatley.student.rit.edu> (raw)
In-Reply-To: <60215.178.73.210.16.1455174198.squirrel@boosthardware.com>
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
prev parent reply other threads:[~2016-02-13 6:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <56BA71D4.5040200@riseup.net>
2016-02-10 21:15 ` Chris Belcher
2016-02-11 7:03 ` Patrick Shirkey
2016-02-12 17:08 ` Danny Thorpe
2016-02-13 6:20 ` Sean Greenslade [this message]
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=20160213062005.GC7436@wheatley.student.rit.edu \
--to=sean@seangreenslade$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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