To Node or Not to Node?

Over a year ago I wondered: how many Bitcoin nodes is enough? It turns out that there are several different perspectives from which one can ask this question, leading to several answers:

• Enough to support demand from SPV clients for connection slots.
• Enough to make it infeasible for any single entity to overwhelm the network with dishonest Sybil nodes.
• Since Bitcoin is trustless, the only node that matters is the node that you run yourself.

Anecdotally, I’ve seen two common reasons stated for not running a node:

1. For enthusiasts who want to run a node at home, it’s usually a bandwidth / quality of service problem. There are tools to help work around this, but most users aren’t sysadmins and would prefer a simple configuration option in the Bitcoin client to throttle the total bandwidth usage. For example, this bandwidth throttling request has been open in Bitcoin Core for 4 years, though I’m hopeful that we’ll see it land as a feature in Bitcoin XT.
2. For businesses, it’s not so much an issue with the resources of installing / running / maintaining a node, it’s an issue with the lack of indexing options offered by bitcoind. Thus the business will also need to run their own indexing solution — an out-of-the-box solution such as Insight or Toshi might work, but for more custom indexing you have to roll your own software — this is where it actually becomes expensive. Depending upon the query volume / latency needs of the business, it may not make sense to bother administering bitcoind instances, the indexing software, and its databases — using a trusted third party API will probably be more cost effective.

A common argument against increasing Bitcoin’s maximum block size is that doing so will increase the cost of resources to run a node and many node operators will shut theirs off, resulting in further centralization of the network infrastructure. This (while being speculative) is a valid point, as there are undoubtedly a number of nodes being run on low-powered hardware that would not be able to keep up with blocks that are significantly larger than today’s 1 MB maximum. However, from a broader perspective I find that the greatest cost to running a node is not CPU, RAM, or bandwidth. The greatest cost is the time required to scale Bitcoin’s learning curve in order to first see the value proposition of running a node and then to learn how to install and administer a node.

One opposing speculative argument is that larger blocks could result in an increase of the total size of Bitcoin’s user base by addressing “The Fidelity Problem.” This would presumably also increase the total number of entities that decide to run nodes, further decentralizing the network. Though I dare not speculate as to which effect would be stronger: causing existing node operators to shut their nodes off or bringing new node operators into the ecosystem.

As I’ve argued in the past, Bitcoin’s value is partially derived from finite physical resources that comprise and secure the network’s infrastructure. Larger blocks support more transactions, but they also incur O(n) overhead in bandwidth, CPU cycles, and data storage. The cost of bearing this load must be paid by node operators. Running a node certainly has real-world costs that shouldn’t be ignored.

I see two primary points of view / objectives clashing in this debate:

• We should prioritize node decentralization and infrastructure stability even if it retards growth of the ecosystem.
• We should push the system’s load as far as we are comfortable in order to accommodate the growth it is experiencing.

It’s clear to me that Bitcoin protocol developers have a responsibility to maintain a stable platform for the ecosystem. I think it’s less clear that they have a responsibility to grow it or ask node operators to expend more resources in order to support more users.

Many people argue that Bitcoin developers should strive to keep it feasible for the average user to run their own node (as opposed to Satoshi’s vision of beefy servers in data centers.) Even with this viewpoint, surely it will be acceptable to eventually increase block sizes as resources become faster and cheaper because it won’t be ‘pricing out’ the average user from running their own node. If this is the case, it seems to me that we have a problem given that there is no established baseline for the acceptable performance or hardware cost requirements to run a node. I’d really like to see further clarification from advocates of this viewpoint regarding the acceptable cost of running a node and how we can measure the global reduction in hardware and bandwidth costs in order to establish a baseline that we can use to justify burdening nodes with additional resource usage.

I find it to be an admirable goal to try to keep node operation costs low and accessible to the average user. On the other hand, if we are able to keep the resource requirements of nodes at the level of, say, whatever the latest Raspberry Pi model on a (global average) residential Internet connection can handle, I’m not sure how helpful it will be if the demand for inclusion in blocks results in transaction fees that price out more users. Stated differently, if the cost or contention of using the network rises to the point of excluding the average user from making transactions, then they probably aren’t going to care that they can run a node at trivial cost. Layer two networks can certainly play a role in easing the burden here, but remember that even users of layer two networks will eventually need to settle onto Bitcoin’s blockchain.

If we’re approaching the block size from a resource usage standpoint, it seems to me that someone is going to be excluded one way or another. Not raising the block size will exclude an unknown number of users from sending transactions while raising the block size will exclude some unknown number of users from running nodes. The latter seems preferable to me because more users will grow the ecosystem, which should increase the value of the ecosystem, and as a result increase the cost that entities are willing to pay to run nodes and hopefully quantity of entities as well. As an operator of several nodes, I can anecdotally state that I find their resource usage to be trivial and I welcome more load.

Bitcoin works because of the incentives built into the system. In the early days of Bitcoin, nodes were synonymous with miners, thus running a node had a direct financial incentive, but the advent of pooled mining destroyed that particular incentive. While some claim that running a node today is purely altruistic, there are indirect incentives for doing so:

• To have a copy of the ledger that you have validated yourself rather than having to trust a third party to be honest about the state of the ledger.
• To protect one’s bitcoin investment by supporting the network.
• To have a local copy of the blockchain for faster querying. Businesses that are parsing the block chain for specific data will find it is orders of magnitude faster to do so on a local copy than by querying services over the Internet.
• To attain the strongest privacy available — SPV clients and web services have the weakest privacy since you are querying third parties for specific addresses and transactions.

However, direct financial incentives are preferable to indirect incentives. I’ve seen a number of people suggest that node operators should receive a cut of mining fees, but the fundamental problem is for a node to be able to prove that it is a real node that hosts the blockchain. Because it’s easy to fake nodes — take the Pseudonode project, for example - one possible solution is Sergio Demian Lerner’s “Proof of Unique Blockchain Storage.”

We could also directly incentivize nodes by allowing them to provide data services in return for fees. In the future, Bitcoin node operation may become synonymous with Lightning Network hub operation, enabling node operators to once again be directly financially incentivized to run nodes. As the operator of a Lightning Network node, you will be able to lock up your bitcoins using smart contracts in order to offer payment channels for public use. Users who transact over your payment channel will pay transaction fees that are collected directly by you.

There are many reasons to run a Bitcoin node, but there is also plenty of room for improvement if we want more people to run nodes. One thing is certain: if you aren’t running a full node, you aren’t making full use of Bitcoin’s features. You can join the financial revolution by buying a hardware node or by following these instructions!