diff options
| author | Danny Thorpe <danny.thorpe@gmail.com> | 2016-02-12 09:08:42 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-02-12 17:08:45 +0000 |
| commit | b4e4726ae861149318e4154d97769fad20f4cb95 (patch) | |
| tree | f1db5a28f8af05ced9b4074cf0ba467904991c0a /ad | |
| parent | 0e8f40778e74c1e86f3288355bafa00ac38d4a04 (diff) | |
| download | pi-bitcoindev-b4e4726ae861149318e4154d97769fad20f4cb95.tar.gz pi-bitcoindev-b4e4726ae861149318e4154d97769fad20f4cb95.zip | |
Re: [bitcoin-dev] Clearing up some misconceptions about full nodes
Diffstat (limited to 'ad')
| -rw-r--r-- | ad/deebb6c06bda359d7babfc8b8dca8a38b89e75 | 732 |
1 files changed, 732 insertions, 0 deletions
diff --git a/ad/deebb6c06bda359d7babfc8b8dca8a38b89e75 b/ad/deebb6c06bda359d7babfc8b8dca8a38b89e75 new file mode 100644 index 000000000..90e5bc3f6 --- /dev/null +++ b/ad/deebb6c06bda359d7babfc8b8dca8a38b89e75 @@ -0,0 +1,732 @@ +Return-Path: <danny.thorpe@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 9C5F6E38 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Feb 2016 17:08:45 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com + [209.85.192.46]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C74BB0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Feb 2016 17:08:43 +0000 (UTC) +Received: by mail-qg0-f46.google.com with SMTP id y89so66840409qge.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Feb 2016 09:08:42 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type; + bh=R+pq0nvs0QvxobThzk8OTsZd2p3YWQmYzm8JFGde1eU=; + b=uMWkM+/JPcuB32aDLfSHvWOjHCWGqmE2iyFGbe+/ZhikbpuuC42+KPUB4L3I5RR+yC + YHYfxVkJFSJLZTen4rjVoO9tbNoCZJIOCYmrQWXUhPSGBhINJYxNGp/6HOcRJS0Qhu9H + Z/pOAszQxvd1+9dsmxZCUO4uwJEqMkwnG0dVoBtcZ1OkOjzqD3CqE5WjycxPbosapwKF + +UJ6gnRccMP0FEYRW9WH3Ku1AYaivPWkkTHJmhS5BniZ7efWMf4+Fj3kpcXf/YTKUBwk + 1Ph2PPmDnruEsfdB+lGW7ai4o/0xb3m6ybx46WNVzhf8Bsju0TVKj8hQOXQ7J5wGpEr8 + tzhg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:date + :message-id:subject:from:to:cc:content-type; + bh=R+pq0nvs0QvxobThzk8OTsZd2p3YWQmYzm8JFGde1eU=; + b=PGxPng5bCxD99wqn31tkHssPchKea7RdLn22U08VuvzaHUhfyHIQLoPbaqwSLmLTue + PMmI17pp4vPDOk+hJ4+1gU0nAXv7zsP7Pky9dqPgECnuP+6aHIzKs4qdS9egwgzQXrvx + B8YoP1AqcTfhv5X4wVE4bCvFfQTK2Ix2T7ljqZKzLPFmuMYKNc92Wc1jttYQpQhbbbCA + D+MWjDPAoP1WRJHlMG7l3HsSzr1uwelzMKM3bxf9MxFHYZz+1pAzwSFIvHhGokEn3VWp + EqnxchP5HmBerOx2sQDpOwn3mwgaOrCA1UTzfTmOyIqwILytzl62J+wEhZKO9/ui+3bv + bwyA== +X-Gm-Message-State: AG10YOS641KIHdAceM2yQiPQPf180XhpVxG4Jsm6Lw2jRfY39uqm3WPdkdEFF27g0KNCJ1P2PVLEBM8FwWVPyQ== +MIME-Version: 1.0 +X-Received: by 10.140.95.117 with SMTP id h108mr3255920qge.65.1455296922226; + Fri, 12 Feb 2016 09:08:42 -0800 (PST) +Received: by 10.140.20.206 with HTTP; Fri, 12 Feb 2016 09:08:42 -0800 (PST) +In-Reply-To: <60215.178.73.210.16.1455174198.squirrel@boosthardware.com> +References: <56BA71D4.5040200@riseup.net> <56BBA879.5030309@riseup.net> + <60215.178.73.210.16.1455174198.squirrel@boosthardware.com> +Date: Fri, 12 Feb 2016 09:08:42 -0800 +Message-ID: <CAJN5wHUBXRdiCcbjZ1bMGhjMzLWZ+6uA9-86gN1UNzLOD78Xcw@mail.gmail.com> +From: Danny Thorpe <danny.thorpe@gmail.com> +To: Patrick Shirkey <pshirkey@boosthardware.com> +Content-Type: multipart/alternative; boundary=001a11c15a8e179526052b95b8d5 +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW + 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: Fri, 12 Feb 2016 20:17:37 +0000 +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +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: Fri, 12 Feb 2016 17:08:45 -0000 + +--001a11c15a8e179526052b95b8d5 +Content-Type: text/plain; charset=UTF-8 + +"With a very powerful "Desktop" machine bitcoin-qt dominates CPU/GPU +resources." + +That doesn't match my experience. + +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. + +Move the Bitcoin data to an SSD, though, and it's an entirely different +story. + +The initial blockchain synchronization / "catch up" 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. + +Running bitcoin-qt occasionally is a much more painful user experience than +running bitcoin-qt continuously. + +I'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've only added RAM and the SSD. + +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. + +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. + +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. + +-Danny + + + +On Wed, Feb 10, 2016 at 11:03 PM, Patrick Shirkey via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> +> On Thu, February 11, 2016 8:15 am, Chris Belcher via bitcoin-dev wrote: +> > I've been asked to post this to this mailing list too. It's time to +> > clear up some misconceptions floating around about full nodes. +> > +> > === Myth: There are only about 5500 full nodes worldwide === +> > +> > This number comes from this and similar sites: https://bitnodes.21.co/ +> > and it measured by trying to probe every nodes on their open ports. +> > +> > Problem is, not all nodes actually have open ports that can be probed. +> > Either because they are behind firewalls or because their users have +> > configured them to not listen for connections. +> > +> > Nobody knows how many full nodes there are, since many people don't know +> > how to forward ports behind a firewall, and bandwidth can be costly, its +> > quite likely that the number of nodes with closed ports is at least +> > another several thousand. +> > +> > Nodes with open ports are able to upload blocks to new full nodes. In +> > all other ways they are the same as nodes with closed ports. But because +> > open-port-nodes can be measured and closed-port-nodes cannot, some +> > members of the bitcoin community have been mistaken into believing that +> > open-port-nodes are that matters. +> > +> > === Myth: This number of nodes matters and/or is too low. === +> > +> > Nodes with open ports are useful to the bitcoin network because they +> > help bootstrap new nodes by uploading historical blocks, they are a +> > measure of bandwidth capacity. Right now there is no shortage of +> > bandwidth capacity, and if there was it could be easily added by renting +> > cloud servers. +> > +> > The problem is not bandwidth or connections, but trust, security and +> > privacy. Let me explain. +> > +> > Full nodes are able to check that all of bitcoin's rules are being +> > followed. Rules like following the inflation schedule, no double +> > spending, no spending of coins that don't belong to the holder of the +> > private key and all the other rules required to make bitcoin work (e.g. +> > difficulty) +> > +> > Full nodes are what make bitcoin trustless. No longer do you have to +> > trust a financial institution like a bank or paypal, you can simply run +> > software on your own computer. To put simply, the only node that matters +> > is the one you use. +> > +> > === Myth: There is no incentive to run nodes, the network relies on +> > altruism === +> > +> > It is very much in the individual bitcoin's users rational self interest +> > to run a full node and use it as their wallet. +> > +> > Using a full node as your wallet is the only way to know for sure that +> > none of bitcoin's rules have been broken. Rules like no coins were spent +> > not belonging to the owner, that no coins were spent twice, that no +> > inflation happens outside of the schedule and that all the rules needed +> > to make the system work are followed (e.g. difficulty.) All other kinds +> > of wallet involve trusting a third party server. +> > +> > All these checks done by full nodes also increase the security. There +> > are many attacks possible against lightweight wallets that do not affect +> > full node wallets. +> > +> > This is not just mindless paranoia, there have been real world examples +> > where full node users were unaffected by turmoil in the rest of the +> > bitcoin ecosystem. The 4th July 2015 accidental chain fork effected many +> > kinds of wallets. Here is the wiki page on this event +> > https://en.bitcoin.it/wiki/July_2015_chain_forks#Wallet_Advice +> > +> > Notice how updated node software was completely unaffected by the fork. +> > All other wallets required either extra confirmations or checking that +> > the third-party institution was running the correct version. +> > +> > Full nodes wallets are also currently the most private way to use +> > Bitcoin, with nobody else learning which bitcoin addresses belong to +> > you. All other lightweight wallets leak information about which +> > addresses are yours because they must query third-party servers. The +> > Electrum servers will know which addresses belong to you and can link +> > them together. Despite bloom filtering, lightweight wallets based on +> > BitcoinJ do not provide much privacy against nodes who connected +> > directly to the wallet or wiretappers. +> > +> > For many use cases, such privacy may not be required. But an important +> > reason to run a full node and use it as a wallet is to get the full +> > privacy benefits. +> > +> > === Myth: I can just set up a node on a cloud server instance and leave +> > it === +> > +> > To get the benefits of running a full node, you must use it as your +> > wallet, preferably on hardware you control. +> > +> > Most people who do this do not use a full node as their wallet. +> > Unfortunately because Bitcoin has a similar name to Bittorrent, some +> > people believe that upload capacity is the most important thing for a +> > healthy network. As I've explained above: bandwidth and connections are +> > not a problem today, trust, security and privacy are. +> > +> > === Myth: Running a full node is not recommended, most people should use +> > a lightweight client === +> > +> > This was common advice in 2012, but since then the full node software +> > has vastly improved in terms of user experience. +> > +> > If you cannot spare the disk space to store the blockchain, you can +> > enable pruning as in: +> > https://bitcoin.org/en/release/v0.11.0#block-file-pruning. In Bitcoin +> > Core 0.12, pruning being enabled will leave the wallet enabled. +> > Altogether this should require less than 1.5GB of hard disk space. +> > +> > If you cannot spare the bandwidth to upload blocks to other nodes, there +> > are number of options to reduce or eliminate the bandwidth requirement +> > found in https://bitcoin.org/en/full-node#reduce-traffic . These include +> > limiting connections, bandwidth targetting and disabling listening. +> > Bitcoin Core 0.12 has the new option -blocksonly, where the node will +> > not download unconfirmed transaction and only download new blocks. This +> > more than halves the bandwidth usage at the expense of not seeing +> > unconfirmed transactions. +> > +> > Synchronizing the blockchain for a new node has improved since 2012 too. +> > Features like headers-first +> > (https://bitcoin.org/en/release/v0.10.0#faster-synchronization) and +> > libsecp256k1 have greatly improved the initial synchronization time. +> > +> > It can be further improved by setting -dbcache=6000 which keeps more of +> > the UTXO set in memory. It reduces the amount of time reading from disk +> > and therefore speeds up synchronization. Tests showed that the entire +> > blockchain can now be synchronized in less than _3 and a half hours_ +> > (See +> > https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-154993958) +> > Note that you'll need Bitcoin Core 0.12 or later to get all these +> > efficiency improvements. +> > +> > === How to run a full node as your wallet === +> > +> > I think every moderate user of bitcoin would benefit by running a full +> > node and using it as their wallet. There are several ways to do this. +> > +> > * Run a bitcoin-qt full node (https://bitcoin.org/en/download). +> > +> > * Use wallet software that is backed by a full node e.g. Armory +> > (https://bitcoinarmory.com/) or JoinMarket +> > (https://github.com/AdamISZ/JMBinary/#jmbinary) +> > +> > * Use a lightweight wallet that connects only to your full node (e.g. +> > Multibit connecting only to your node running at home, Electrum +> > connecting only to your own Electrum server) +> > +> > So what are you waiting for? The benefits are many, the downsides are +> > not that bad. The more people do this, the more robust and healthy the +> > bitcoin ecosystem is. +> > +> > +> +> 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. +> +> 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). +> +> 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? +> +> For example Debian unstable currently provides the following: +> +> apt-cache madison bitcoin-qt +> bitcoin-qt | 0.11.2-1 | http://ftp.lug.ro/debian/ unstable/main amd64 +> Packages +> bitcoin | 0.11.2-1 | http://ftp.lug.ro/debian/ unstable/main Sources +> +> +> 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. +> +> Compare that to the requirements for spinning up "bitcoin-2.0" and +> enabling users to move their wallets to the new blockchain at their +> leisure. +> +> The ecosystem doesn't suffer from instant degradation. Bitcoin "brand" +> loyalty will ensure that users who want to move forward with the economic +> potential of the 2MB blocksize will be able to keep their existing funds +> safe while testing the waters with the new blocksize. +> +> After all Bitcoin is still the only game in town when it comes to scale +> and proven history of financial return. +> +> As the new blockchain builds momentum the old one will eventually become +> obsolete. However it may also become the digital equivalency of Silver and +> that is also a useful, profitable and viable alternative with a proven +> history of success. +> +> +> +> +> -- +> Patrick Shirkey +> Boost Hardware Ltd +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--001a11c15a8e179526052b95b8d5 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">"<span style=3D"font-size:12.8px">With a very powerfu= +l "Desktop" machine bitcoin-qt dominates CPU/GPU</span><br style= +=3D"font-size:12.8px"><span style=3D"font-size:12.8px">resources."</sp= +an><div><span style=3D"font-size:12.8px"><br></span></div><div><span style= +=3D"font-size:12.8px">That doesn't match my experience.=C2=A0</span></d= +iv><div><span style=3D"font-size:12.8px"><br></span></div><div><span style= +=3D"font-size:12.8px">System responsiveness / user experience can suffer wh= +en 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></di= +v><div><span style=3D"font-size:12.8px"><br></span></div><div><span style= +=3D"font-size:12.8px">Move the Bitcoin data to an SSD, though, and it's= + an entirely different story.</span><br></div><div><br></div><div><span sty= +le=3D"font-size:12.8px">The initial blockchain synchronization / "catc= +h up" 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. =C2=A0</span></div><div><span style=3D"font-size:12.8= +px"><br></span></div><div><span style=3D"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=3D"font-size:12.8px"><br></s= +pan></div><div><span style=3D"font-size:12.8px">I'm running Bitcoin Cor= +e v0.12.rc2 on an old dual core Pentium E2160 at 1.8GHz, 6GB RAM, 64 bit Wi= +ndows 10, with the Bitcoin data on SSD. This system is about 6 years old an= +d was an economy model even when new. Not what I would call a powerful syst= +em. I've only added RAM and the SSD.</span></div><div><span style=3D"fo= +nt-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">On t= +hat machine I run two instances of Bitcoin-qt - one for mainnet, and anothe= +r 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 th= +eir max of 25 connections (each). Total CPU load floats around 11%, with on= +ly occasional spikes to 40% for a few seconds.=C2=A0 The mainnet bitcoin-qt= + process uses about 700MB of RAM, testnet about 300MB.</span></div><div><sp= +an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz= +e: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 Bit= +coin data was on a spinning disk. Moving the Bitcoin data to an SSD drive h= +ad the greatest impact on breaking the disk-bound whole-system paralysis. I= +ncreasing the system RAM, upgrading to v0.12, and upgrading the OS to Win 1= +0 all contributed smaller improvements.</span></div><div><span style=3D"fon= +t-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">It is= + possible to run a full node on a small desktop machine concurrent with use= +r 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.</sp= +an></div><div><span style=3D"font-size:12.8px"><br></span></div><div><span = +style=3D"font-size:12.8px">-Danny</span></div><div><span style=3D"font-size= +:12.8px"><br></span></div><div><br></div></div><div class=3D"gmail_extra"><= +br><div class=3D"gmail_quote">On Wed, Feb 10, 2016 at 11:03 PM, Patrick Shi= +rkey via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@li= +sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio= +n.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m= +argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D= +"HOEnZb"><div class=3D"h5"><br> +On Thu, February 11, 2016 8:15 am, Chris Belcher via bitcoin-dev wrote:<br> +> I've been asked to post this to this mailing list too. It's ti= +me to<br> +> clear up some misconceptions floating around about full nodes.<br> +><br> +> =3D=3D=3D Myth: There are only about 5500 full nodes worldwide =3D=3D= +=3D<br> +><br> +> This number comes from this and similar sites: <a href=3D"https://bitn= +odes.21.co/" rel=3D"noreferrer" target=3D"_blank">https://bitnodes.21.co/</= +a><br> +> and it measured by trying to probe every nodes on their open ports.<br= +> +><br> +> Problem is, not all nodes actually have open ports that can be probed.= +<br> +> Either because they are behind firewalls or because their users have<b= +r> +> configured them to not listen for connections.<br> +><br> +> Nobody knows how many full nodes there are, since many people don'= +t know<br> +> how to forward ports behind a firewall, and bandwidth can be costly, i= +ts<br> +> quite likely that the number of nodes with closed ports is at least<br= +> +> another several thousand.<br> +><br> +> Nodes with open ports are able to upload blocks to new full nodes. In<= +br> +> all other ways they are the same as nodes with closed ports. But becau= +se<br> +> open-port-nodes can be measured and closed-port-nodes cannot, some<br> +> members of the bitcoin community have been mistaken into believing tha= +t<br> +> open-port-nodes are that matters.<br> +><br> +> =3D=3D=3D Myth: This number of nodes matters and/or is too low. =3D=3D= +=3D<br> +><br> +> Nodes with open ports are useful to the bitcoin network because they<b= +r> +> help bootstrap new nodes by uploading historical blocks, they are a<br= +> +> measure of bandwidth capacity. Right now there is no shortage of<br> +> bandwidth capacity, and if there was it could be easily added by renti= +ng<br> +> cloud servers.<br> +><br> +> The problem is not bandwidth or connections, but trust, security and<b= +r> +> privacy. Let me explain.<br> +><br> +> Full nodes are able to check that all of bitcoin's rules are being= +<br> +> followed. Rules like following the inflation schedule, no double<br> +> spending, no spending of coins that don't belong to the holder of = +the<br> +> private key and all the other rules required to make bitcoin work (e.g= +.<br> +> difficulty)<br> +><br> +> Full nodes are what make bitcoin trustless. No longer do you have to<b= +r> +> trust a financial institution like a bank or paypal, you can simply ru= +n<br> +> software on your own computer. To put simply, the only node that matte= +rs<br> +> is the one you use.<br> +><br> +> =3D=3D=3D Myth: There is no incentive to run nodes, the network relies= + on<br> +> altruism =3D=3D=3D<br> +><br> +> It is very much in the individual bitcoin's users rational self in= +terest<br> +> to run a full node and use it as their wallet.<br> +><br> +> Using a full node as your wallet is the only way to know for sure that= +<br> +> none of bitcoin's rules have been broken. Rules like no coins were= + spent<br> +> not belonging to the owner, that no coins were spent twice, that no<br= +> +> inflation happens outside of the schedule and that all the rules neede= +d<br> +> to make the system work are followed=C2=A0 (e.g. difficulty.) All othe= +r kinds<br> +> of wallet involve trusting a third party server.<br> +><br> +> All these checks done by full nodes also increase the security. There<= +br> +> are many attacks possible against lightweight wallets that do not affe= +ct<br> +> full node wallets.<br> +><br> +> This is not just mindless paranoia, there have been real world example= +s<br> +> where full node users were unaffected by turmoil in the rest of the<br= +> +> bitcoin ecosystem. The 4th July 2015 accidental chain fork effected ma= +ny<br> +> kinds of wallets. Here is the wiki page on this event<br> +> <a href=3D"https://en.bitcoin.it/wiki/July_2015_chain_forks#Wallet_Adv= +ice" rel=3D"noreferrer" target=3D"_blank">https://en.bitcoin.it/wiki/July_2= +015_chain_forks#Wallet_Advice</a><br> +><br> +> Notice how updated node software was completely unaffected by the fork= +.<br> +> All other wallets required either extra confirmations or checking that= +<br> +> the third-party institution was running the correct version.<br> +><br> +> Full nodes wallets are also currently the most private way to use<br> +> Bitcoin, with nobody else learning which bitcoin addresses belong to<b= +r> +> you. All other lightweight wallets leak information about which<br> +> addresses are yours because they must query third-party servers. The<b= +r> +> Electrum servers will know which addresses belong to you and can link<= +br> +> them together. Despite bloom filtering, lightweight wallets based on<b= +r> +> BitcoinJ do not provide much privacy against nodes who connected<br> +> directly to the wallet or wiretappers.<br> +><br> +> For many use cases, such privacy may not be required. But an important= +<br> +> reason to run a full node and use it as a wallet is to get the full<br= +> +> privacy benefits.<br> +><br> +> =3D=3D=3D Myth: I can just set up a node on a cloud server instance an= +d leave<br> +> it =3D=3D=3D<br> +><br> +> To get the benefits of running a full node, you must use it as your<br= +> +> wallet, preferably on hardware you control.<br> +><br> +> Most people who do this do not use a full node as their wallet.<br> +> Unfortunately because Bitcoin has a similar name to Bittorrent, some<b= +r> +> people believe that upload capacity is the most important thing for a<= +br> +> healthy network. As I've explained above: bandwidth and connection= +s are<br> +> not a problem today, trust, security and privacy are.<br> +><br> +> =3D=3D=3D Myth: Running a full node is not recommended, most people sh= +ould use<br> +> a lightweight client =3D=3D=3D<br> +><br> +> This was common advice in 2012, but since then the full node software<= +br> +> has vastly improved in terms of user experience.<br> +><br> +> If you cannot spare the disk space to store the blockchain, you can<br= +> +> enable pruning as in:<br> +> <a href=3D"https://bitcoin.org/en/release/v0.11.0#block-file-pruning" = +rel=3D"noreferrer" target=3D"_blank">https://bitcoin.org/en/release/v0.11.0= +#block-file-pruning</a>. In Bitcoin<br> +> Core 0.12, pruning being enabled will leave the wallet enabled.<br> +> Altogether this should require less than 1.5GB of hard disk space.<br> +><br> +> If you cannot spare the bandwidth to upload blocks to other nodes, the= +re<br> +> are number of options to reduce or eliminate the bandwidth requirement= +<br> +> found in <a href=3D"https://bitcoin.org/en/full-node#reduce-traffic" r= +el=3D"noreferrer" target=3D"_blank">https://bitcoin.org/en/full-node#reduce= +-traffic</a> . These include<br> +> limiting connections, bandwidth targetting and disabling listening.<br= +> +> Bitcoin Core 0.12 has the new option -blocksonly, where the node will<= +br> +> not download unconfirmed transaction and only download new blocks. Thi= +s<br> +> more than halves the bandwidth usage at the expense of not seeing<br> +> unconfirmed transactions.<br> +><br> +> Synchronizing the blockchain for a new node has improved since 2012 to= +o.<br> +> Features like headers-first<br> +> (<a href=3D"https://bitcoin.org/en/release/v0.10.0#faster-synchronizat= +ion" rel=3D"noreferrer" target=3D"_blank">https://bitcoin.org/en/release/v0= +.10.0#faster-synchronization</a>) and<br> +> libsecp256k1 have greatly improved the initial synchronization time.<b= +r> +><br> +> It can be further improved by setting -dbcache=3D6000 which keeps more= + of<br> +> the UTXO set in memory. It reduces the amount of time reading from dis= +k<br> +> and therefore speeds up synchronization. Tests showed that the entire<= +br> +> blockchain can now be synchronized in less than _3 and a half hours_<b= +r> +> (See<br> +> <a href=3D"https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-1= +54993958" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/b= +itcoin/pull/6954#issuecomment-154993958</a>)<br> +> Note that you'll need Bitcoin Core 0.12 or later to get all these<= +br> +> efficiency improvements.<br> +><br> +> =3D=3D=3D How to run a full node as your wallet =3D=3D=3D<br> +><br> +> I think every moderate user of bitcoin would benefit by running a full= +<br> +> node and using it as their wallet. There are several ways to do this.<= +br> +><br> +> * Run a bitcoin-qt full node (<a href=3D"https://bitcoin.org/en/downlo= +ad" rel=3D"noreferrer" target=3D"_blank">https://bitcoin.org/en/download</a= +>).<br> +><br> +> * Use wallet software that is backed by a full node e.g. Armory<br> +> (<a href=3D"https://bitcoinarmory.com/" rel=3D"noreferrer" target=3D"_= +blank">https://bitcoinarmory.com/</a>) or JoinMarket<br> +> (<a href=3D"https://github.com/AdamISZ/JMBinary/#jmbinary" rel=3D"nore= +ferrer" target=3D"_blank">https://github.com/AdamISZ/JMBinary/#jmbinary</a>= +)<br> +><br> +> * Use a lightweight wallet that connects only to your full node (e.g.<= +br> +> Multibit connecting only to your node running at home, Electrum<br> +> connecting only to your own Electrum server)<br> +><br> +> So what are you waiting for? The benefits are many, the downsides are<= +br> +> not that bad. The more people do this, the more robust and healthy the= +<br> +> bitcoin ecosystem is.<br> +><br> +><br> +<br> +</div></div>This is very useful information but from my experience it is no= +t 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 "Desktop" machine bitcoin-qt dominates CPU/G= +PU<br> +resources. Surely the majority of nodes NOT running open ports are being<br= +> +run on desktop systems.=C2=A0 It's likely that the vast majority of the= +<br> +"normal/desktop" user base are not going to setup dedicated machi= +nes to<br> +run a full node full time.<br> +<br> +It's likely that the vast majority of full nodes that are not running o= +pen<br> +ports are used occasionally when the user wants to make a transaction or<br= +> +"catch up" 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<b= +r> +not (majority).<br> +<br> +Does the power of p2p decentralization lie with the vast majority or the<br= +> +"wealthy" 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=C2=A0 madison bitcoin-qt<br> +bitcoin-qt |=C2=A0 =C2=A00.11.2-1 | <a href=3D"http://ftp.lug.ro/debian/" r= +el=3D"noreferrer" target=3D"_blank">http://ftp.lug.ro/debian/</a> unstable/= +main amd64<br> +Packages<br> +=C2=A0 =C2=A0bitcoin |=C2=A0 =C2=A00.11.2-1 | <a href=3D"http://ftp.lug.ro/= +debian/" rel=3D"noreferrer" target=3D"_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'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's should be a lesson for those who seek= +<br> +that route.<br> +<br> +Compare that to the requirements for spinning up "bitcoin-2.0" an= +d<br> +enabling users to move their wallets to the new blockchain at their<br> +leisure.<br> +<br> +The ecosystem doesn't suffer from instant degradation. Bitcoin "br= +and"<br> +loyalty will ensure that users who want to move forward with the economic<b= +r> +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=3D"HOEnZb"><div class=3D"h5">___________________________________= +____________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</div></div></blockquote></div><br></div> + +--001a11c15a8e179526052b95b8d5-- + |