From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5171BE90 for ; Wed, 10 Feb 2016 21:15:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7859C2F for ; Wed, 10 Feb 2016 21:15:45 +0000 (UTC) Received: from piha.riseup.net (unknown [10.0.1.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 395ED1A1A42 for ; Wed, 10 Feb 2016 21:15:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1455138945; bh=w2DrlT2aKqhu7ObzAdu1obtaxCAKwwWvk0F+l+VzXFY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=M3AUo0fpgrcBcEyyjbQ+F3lm0XSvckEXJnUJB9jlxxxFYTizB7E0b1qRE0WTMOcOJ mV3qS9ozRMXSgtLMtXrzk5J0KtGvCL+kU70/o5UoQ8LPb3CAcJ0IZKuYt96pkThLes FGVRyXE81dpzKN2Ch2Xp1rwbEwg4veoRWLRf9h+Y= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: belcher) with ESMTPSA id A9A4D1C0024 Message-ID: <56BBA879.5030309@riseup.net> Date: Wed, 10 Feb 2016 21:15:37 +0000 From: Chris Belcher MIME-Version: 1.0 To: bitcoin-dev@lists.linuxfoundation.org References: <56BA71D4.5040200@riseup.net> In-Reply-To: <56BA71D4.5040200@riseup.net> X-Forwarded-Message-Id: <56BA71D4.5040200@riseup.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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 21:59:06 +0000 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 21:15:46 -0000 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.