<div dir="ltr">&quot;<span style="font-size:12.8px">With a very powerful &quot;Desktop&quot; machine bitcoin-qt dominates CPU/GPU</span><br style="font-size:12.8px"><span style="font-size:12.8px">resources.&quot;</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">That doesn&#39;t match my experience. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">System responsiveness / user experience can suffer when running bitcoin-qt on a spinning hard disk. Disk I/O load will cause the whole system to grind and severely disrupt the user experience.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Move the Bitcoin data to an SSD, though, and it&#39;s an entirely different story.</span><br></div><div><br></div><div><span style="font-size:12.8px">The initial blockchain synchronization / &quot;catch up&quot; is CPU and disk intensive, but after initial sync I find bitcoin-qt uses only a trivial amount of CPU to keep up with verifying new blocks and new transactions.  </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Running bitcoin-qt occasionally is a much more painful user experience than running bitcoin-qt continuously.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I&#39;m running Bitcoin Core v0.12.rc2 on an old dual core Pentium E2160 at 1.8GHz, 6GB RAM, 64 bit Windows 10, with the Bitcoin data on SSD. This system is about 6 years old and was an economy model even when new. Not what I would call a powerful system. I&#39;ve only added RAM and the SSD.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">On that machine I run two instances of Bitcoin-qt - one for mainnet, and another for testnet, and an instance of bfgminer to manage a handful of USB Block Eruptors for testnet mining. Both bitcoin-qt instances are typically at their max of 25 connections (each). Total CPU load floats around 11%, with only occasional spikes to 40% for a few seconds.  The mainnet bitcoin-qt process uses about 700MB of RAM, testnet about 300MB.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This machine did fall into disk grinding paralysis during initial sync / catchup with the v0.10 and v0.11 builds of bitcoin-qt, when the Bitcoin data was on a spinning disk. Moving the Bitcoin data to an SSD drive had the greatest impact on breaking the disk-bound whole-system paralysis. Increasing the system RAM, upgrading to v0.12, and upgrading the OS to Win 10 all contributed smaller improvements.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It is possible to run a full node on a small desktop machine concurrent with user apps. Just get the Bitcoin data off of spinning media and onto SSD, make sure you have plenty of RAM, and leave bitcoin-qt running all the time.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">-Danny</span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 11:03 PM, Patrick Shirkey via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Thu, February 11, 2016 8:15 am, Chris Belcher via bitcoin-dev wrote:<br>
&gt; I&#39;ve been asked to post this to this mailing list too. It&#39;s time to<br>
&gt; clear up some misconceptions floating around about full nodes.<br>
&gt;<br>
&gt; === Myth: There are only about 5500 full nodes worldwide ===<br>
&gt;<br>
&gt; This number comes from this and similar sites: <a href="https://bitnodes.21.co/" rel="noreferrer" target="_blank">https://bitnodes.21.co/</a><br>
&gt; and it measured by trying to probe every nodes on their open ports.<br>
&gt;<br>
&gt; Problem is, not all nodes actually have open ports that can be probed.<br>
&gt; Either because they are behind firewalls or because their users have<br>
&gt; configured them to not listen for connections.<br>
&gt;<br>
&gt; Nobody knows how many full nodes there are, since many people don&#39;t know<br>
&gt; how to forward ports behind a firewall, and bandwidth can be costly, its<br>
&gt; quite likely that the number of nodes with closed ports is at least<br>
&gt; another several thousand.<br>
&gt;<br>
&gt; Nodes with open ports are able to upload blocks to new full nodes. In<br>
&gt; all other ways they are the same as nodes with closed ports. But because<br>
&gt; open-port-nodes can be measured and closed-port-nodes cannot, some<br>
&gt; members of the bitcoin community have been mistaken into believing that<br>
&gt; open-port-nodes are that matters.<br>
&gt;<br>
&gt; === Myth: This number of nodes matters and/or is too low. ===<br>
&gt;<br>
&gt; Nodes with open ports are useful to the bitcoin network because they<br>
&gt; help bootstrap new nodes by uploading historical blocks, they are a<br>
&gt; measure of bandwidth capacity. Right now there is no shortage of<br>
&gt; bandwidth capacity, and if there was it could be easily added by renting<br>
&gt; cloud servers.<br>
&gt;<br>
&gt; The problem is not bandwidth or connections, but trust, security and<br>
&gt; privacy. Let me explain.<br>
&gt;<br>
&gt; Full nodes are able to check that all of bitcoin&#39;s rules are being<br>
&gt; followed. Rules like following the inflation schedule, no double<br>
&gt; spending, no spending of coins that don&#39;t belong to the holder of the<br>
&gt; private key and all the other rules required to make bitcoin work (e.g.<br>
&gt; difficulty)<br>
&gt;<br>
&gt; Full nodes are what make bitcoin trustless. No longer do you have to<br>
&gt; trust a financial institution like a bank or paypal, you can simply run<br>
&gt; software on your own computer. To put simply, the only node that matters<br>
&gt; is the one you use.<br>
&gt;<br>
&gt; === Myth: There is no incentive to run nodes, the network relies on<br>
&gt; altruism ===<br>
&gt;<br>
&gt; It is very much in the individual bitcoin&#39;s users rational self interest<br>
&gt; to run a full node and use it as their wallet.<br>
&gt;<br>
&gt; Using a full node as your wallet is the only way to know for sure that<br>
&gt; none of bitcoin&#39;s rules have been broken. Rules like no coins were spent<br>
&gt; not belonging to the owner, that no coins were spent twice, that no<br>
&gt; inflation happens outside of the schedule and that all the rules needed<br>
&gt; to make the system work are followed  (e.g. difficulty.) All other kinds<br>
&gt; of wallet involve trusting a third party server.<br>
&gt;<br>
&gt; All these checks done by full nodes also increase the security. There<br>
&gt; are many attacks possible against lightweight wallets that do not affect<br>
&gt; full node wallets.<br>
&gt;<br>
&gt; This is not just mindless paranoia, there have been real world examples<br>
&gt; where full node users were unaffected by turmoil in the rest of the<br>
&gt; bitcoin ecosystem. The 4th July 2015 accidental chain fork effected many<br>
&gt; kinds of wallets. Here is the wiki page on this event<br>
&gt; <a href="https://en.bitcoin.it/wiki/July_2015_chain_forks#Wallet_Advice" rel="noreferrer" target="_blank">https://en.bitcoin.it/wiki/July_2015_chain_forks#Wallet_Advice</a><br>
&gt;<br>
&gt; Notice how updated node software was completely unaffected by the fork.<br>
&gt; All other wallets required either extra confirmations or checking that<br>
&gt; the third-party institution was running the correct version.<br>
&gt;<br>
&gt; Full nodes wallets are also currently the most private way to use<br>
&gt; Bitcoin, with nobody else learning which bitcoin addresses belong to<br>
&gt; you. All other lightweight wallets leak information about which<br>
&gt; addresses are yours because they must query third-party servers. The<br>
&gt; Electrum servers will know which addresses belong to you and can link<br>
&gt; them together. Despite bloom filtering, lightweight wallets based on<br>
&gt; BitcoinJ do not provide much privacy against nodes who connected<br>
&gt; directly to the wallet or wiretappers.<br>
&gt;<br>
&gt; For many use cases, such privacy may not be required. But an important<br>
&gt; reason to run a full node and use it as a wallet is to get the full<br>
&gt; privacy benefits.<br>
&gt;<br>
&gt; === Myth: I can just set up a node on a cloud server instance and leave<br>
&gt; it ===<br>
&gt;<br>
&gt; To get the benefits of running a full node, you must use it as your<br>
&gt; wallet, preferably on hardware you control.<br>
&gt;<br>
&gt; Most people who do this do not use a full node as their wallet.<br>
&gt; Unfortunately because Bitcoin has a similar name to Bittorrent, some<br>
&gt; people believe that upload capacity is the most important thing for a<br>
&gt; healthy network. As I&#39;ve explained above: bandwidth and connections are<br>
&gt; not a problem today, trust, security and privacy are.<br>
&gt;<br>
&gt; === Myth: Running a full node is not recommended, most people should use<br>
&gt; a lightweight client ===<br>
&gt;<br>
&gt; This was common advice in 2012, but since then the full node software<br>
&gt; has vastly improved in terms of user experience.<br>
&gt;<br>
&gt; If you cannot spare the disk space to store the blockchain, you can<br>
&gt; enable pruning as in:<br>
&gt; <a href="https://bitcoin.org/en/release/v0.11.0#block-file-pruning" rel="noreferrer" target="_blank">https://bitcoin.org/en/release/v0.11.0#block-file-pruning</a>. In Bitcoin<br>
&gt; Core 0.12, pruning being enabled will leave the wallet enabled.<br>
&gt; Altogether this should require less than 1.5GB of hard disk space.<br>
&gt;<br>
&gt; If you cannot spare the bandwidth to upload blocks to other nodes, there<br>
&gt; are number of options to reduce or eliminate the bandwidth requirement<br>
&gt; found in <a href="https://bitcoin.org/en/full-node#reduce-traffic" rel="noreferrer" target="_blank">https://bitcoin.org/en/full-node#reduce-traffic</a> . These include<br>
&gt; limiting connections, bandwidth targetting and disabling listening.<br>
&gt; Bitcoin Core 0.12 has the new option -blocksonly, where the node will<br>
&gt; not download unconfirmed transaction and only download new blocks. This<br>
&gt; more than halves the bandwidth usage at the expense of not seeing<br>
&gt; unconfirmed transactions.<br>
&gt;<br>
&gt; Synchronizing the blockchain for a new node has improved since 2012 too.<br>
&gt; Features like headers-first<br>
&gt; (<a href="https://bitcoin.org/en/release/v0.10.0#faster-synchronization" rel="noreferrer" target="_blank">https://bitcoin.org/en/release/v0.10.0#faster-synchronization</a>) and<br>
&gt; libsecp256k1 have greatly improved the initial synchronization time.<br>
&gt;<br>
&gt; It can be further improved by setting -dbcache=6000 which keeps more of<br>
&gt; the UTXO set in memory. It reduces the amount of time reading from disk<br>
&gt; and therefore speeds up synchronization. Tests showed that the entire<br>
&gt; blockchain can now be synchronized in less than _3 and a half hours_<br>
&gt; (See<br>
&gt; <a href="https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-154993958" rel="noreferrer" target="_blank">https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-154993958</a>)<br>
&gt; Note that you&#39;ll need Bitcoin Core 0.12 or later to get all these<br>
&gt; efficiency improvements.<br>
&gt;<br>
&gt; === How to run a full node as your wallet ===<br>
&gt;<br>
&gt; I think every moderate user of bitcoin would benefit by running a full<br>
&gt; node and using it as their wallet. There are several ways to do this.<br>
&gt;<br>
&gt; * Run a bitcoin-qt full node (<a href="https://bitcoin.org/en/download" rel="noreferrer" target="_blank">https://bitcoin.org/en/download</a>).<br>
&gt;<br>
&gt; * Use wallet software that is backed by a full node e.g. Armory<br>
&gt; (<a href="https://bitcoinarmory.com/" rel="noreferrer" target="_blank">https://bitcoinarmory.com/</a>) or JoinMarket<br>
&gt; (<a href="https://github.com/AdamISZ/JMBinary/#jmbinary" rel="noreferrer" target="_blank">https://github.com/AdamISZ/JMBinary/#jmbinary</a>)<br>
&gt;<br>
&gt; * Use a lightweight wallet that connects only to your full node (e.g.<br>
&gt; Multibit connecting only to your node running at home, Electrum<br>
&gt; connecting only to your own Electrum server)<br>
&gt;<br>
&gt; So what are you waiting for? The benefits are many, the downsides are<br>
&gt; not that bad. The more people do this, the more robust and healthy the<br>
&gt; bitcoin ecosystem is.<br>
&gt;<br>
&gt;<br>
<br>
</div></div>This is very useful information but from my experience it is not viable to<br>
have a full node running full time on a desktop system i.e sharing the<br>
system with a normal desktop workload.<br>
<br>
With a very powerful &quot;Desktop&quot; machine bitcoin-qt dominates CPU/GPU<br>
resources. Surely the majority of nodes NOT running open ports are being<br>
run on desktop systems.  It&#39;s likely that the vast majority of the<br>
&quot;normal/desktop&quot; user base are not going to setup dedicated machines to<br>
run a full node full time.<br>
<br>
It&#39;s likely that the vast majority of full nodes that are not running open<br>
ports are used occasionally when the user wants to make a transaction or<br>
&quot;catch up&quot; with the blockchain.<br>
<br>
That creates a divide between those who do have the resources to<br>
contribute to the system on a full time basis (minority) and those who do<br>
not (majority).<br>
<br>
Does the power of p2p decentralization lie with the vast majority or the<br>
&quot;wealthy&quot; resource rich minority?<br>
<br>
How will the move to 2MB hard fork affect the vast majority of nodes?<br>
<br>
For example Debian unstable currently provides the following:<br>
<br>
apt-cache  madison bitcoin-qt<br>
bitcoin-qt |   0.11.2-1 | <a href="http://ftp.lug.ro/debian/" rel="noreferrer" target="_blank">http://ftp.lug.ro/debian/</a> unstable/main amd64<br>
Packages<br>
   bitcoin |   0.11.2-1 | <a href="http://ftp.lug.ro/debian/" rel="noreferrer" target="_blank">http://ftp.lug.ro/debian/</a> unstable/main Sources<br>
<br>
<br>
The rollout affect of the hard fork on the entire bitcoin ecosystem is a<br>
difficult process to plan in advance. It&#39;s not viable to simply rely on<br>
press releases to encourage users to upgrade their nodes. The debacle with<br>
Pulse Audio during the mid 2000&#39;s should be a lesson for those who seek<br>
that route.<br>
<br>
Compare that to the requirements for spinning up &quot;bitcoin-2.0&quot; and<br>
enabling users to move their wallets to the new blockchain at their<br>
leisure.<br>
<br>
The ecosystem doesn&#39;t suffer from instant degradation. Bitcoin &quot;brand&quot;<br>
loyalty will ensure that users who want to move forward with the economic<br>
potential of the 2MB blocksize will be able to keep their existing funds<br>
safe while testing the waters with the new blocksize.<br>
<br>
After all Bitcoin is still the only game in town when it comes to scale<br>
and proven history of financial return.<br>
<br>
As the new blockchain builds momentum the old one will eventually become<br>
obsolete. However it may also become the digital equivalency of Silver and<br>
that is also a useful, profitable and viable alternative with a proven<br>
history of success.<br>
<br>
<br>
<br>
<br>
--<br>
Patrick Shirkey<br>
Boost Hardware Ltd<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>