Bitcoin Cash, Memo, and the Public Goods Fallacy

9 min readApr 29, 2018

For many years, there has been a recurring argument against on-chain scaling based on the idea that the blockchain is a “database that must store everything, forever”. This argument is often accepted uncritically, even among some big-blockers who accept the premise, but argue that larger blocks are still feasible even with all nodes “storing everything forever”.

The recent emergence of applications such as Memo (memo.cash) has raised concerns for some Bitcoin Cash proponents [1]. These people want Bitcoin Cash to be the best form of money possible, and the idea of alternate uses using up limited block space is seen as having a negative impact on the primary use-case of money.

In this article, I will argue that the “storing everything forever” argument is flawed, and is a case of the Public Goods fallacy. This fallacy is used as justification for central planning which should be rejected in favor of a market-based approach. With such an approach, we don’t need to worry about block space being crowded out, or that non-monetary uses will detract from Bitcoin Cash as money.

Block Space as a Public Good

Although the concept of a “Public Good” is a flawed economic concept, it is widely accepted by many economists and mainstream publications [2]. In this article, I will not delve into the general theory of Public Goods, there are many good resources elsewhere explaining why the concept is unsound [3]. Instead, this article will focus only on the specific case of blockchains, and the technical and economic reasons Public Goods arguments do not apply.

The idea that blockchains are a type of Public Good rests on two premises:

That blockchains function as an “add-only” database, that grows continually, and where all the nodes on the network must store all the data forever.
That the costs of maintaining, storing, and serving up blockchain data are not borne by those who benefit from those services. Transactors pay an initial fee to miners, but then all nodes on the network must bear the costs in perpetuity.

This conceptual framework leads to attempts to centrally plan the network by implementing technical measures to limit excessive or unwanted uses of the blockchain. Some examples of such measures would be limiting the OP_RETURN size, the Segwit “witness discount” block weight accounting, and the block size limit itself.

A good example of the Public Goods argument was recently articulated by Vlad Zamfir of Ethereum, when he said “I think it’s crazy that the network would bear a cost forever, for a revenue earned once by a single party”. He then goes on to advocate the creation of some sort of network “rent” to mitigate the problem [4].

In the next two sections, I will discuss each of the two premises of the Public Goods argument in more detail.

Blockchain Data Structure

It is natural to conceptualize a blockchain as a large ever-growing database. After all, since blocks are always added in in ever-growing chain, it’s hard to see how it could be otherwise. Current full-node implementations typically store all the blocks in the chain, and anyone who has ever run their own full node knows that the size required to store the blockchain keeps growing year after year.

It is also easy to find examples of well known figures in the cryptocurrency community stating various forms of the “ever-growing database” idea:

Explaining what a blockchain is to lay audiences: “A database that stores everything forever — in other words: the most inefficient database on the planet.”

— Tuur Demeester [5]

Why you don’t want a blockchain —
1. Storage: Everyone has to store everything
2. Bandwidth: Everything has to be broadcast to everyone
3. CPU: Everyone has to validate everything
4. Development: Everything is 10x harder
5. Control: Everyone collectively has control, not you

— Jimmy Song [6]

To understand the problem with these statements, we need to zoom in a bit and look at the blockchain data structure in more detail.

The blockchain contains data that is cryptographically linked together in various ways: block headers are linked together in linear chain, transactions are linked to the block headers in Merkle trees, and transactions are linked to each other in a Directed Acyclic Graph (DAG) linking transaction inputs to previous outputs. Let’s think about why the blockchain is structured this way. If it were to be a giant database that required everyone to store all the data, then these structures would be overkill. For example, why build a Merkle tree instead of just hashing all the transactions directly together? The reason is that a Merkle tree allows us to prove things about a subset of all the transactions: we can prove that a transaction is included in a block without knowing all the other transactions in that block. In fact, this is what allows SPV wallets to function without downloading the whole blockchain.

Extremely simplified diagram showing the connections between transactions in a blockchain

Similarly, the blockchain data structure can be used to prove various other things without needing to possess the entire blockchain: that a transaction input exists, or that a particular output has been spent. Other facts about blockchain data may take more information to prove. For example, proving that a transaction is absent from a block currently requires checking all the transactions in the block. However, these proofs could be made efficient in the future with improvements to the protocol such as canonical transaction ordering [7].

As long as one node saves a copy of a transaction and a Merkle proof, they can prove to all others on the network that the transaction was in a block. This provides a mechanism whereby everyone does not need to store all the data forever; only those who value the data need store it, and they can prove its validity later. Similarly, other types of information are also provable with subsets of the blockchain data, and more can be made possible with future developments. Those who value proving certain facts about data in the blockchain will be able, and have the incentive, to save the necessary data without storing the entire blockchain.

Alignment of Costs and Benefits

We have established that it is possible for people to use blockchain without storing the entire history of data (SPV wallets do it everyday), but what about the incentive problem of “free riding” on those who serve up the needed data? We see this currently with SPV wallets: they rely on full nodes to store the needed data and provide it to them when needed. This puts a burden on full nodes for which they are not remunerated. If the number of SPV wallets grows faster than the number of full nodes, this imbalance will only grow greater.

One possible approach to this problem is to design limits to the system such that the cost of running a full node is capped. These limits can apply to block space, Sigops, UTXO creation, or any other parameter that results in a cost to node operation. This approach is often taken by designers of a system, as can be seen in Vlad Zamfir’s “rent” proposal, or Bitcoin Core’s block size limit.

It soon becomes obvious, however, that if demand to use the system grows, and becomes constrained by these limits, that they act as economic quotas. As with all quotas they cause loss of value and perverse outcomes.

Markets are the alternative to quotas. We just need to think of ways to enable and facilitate markets. This article will not go into great detail on market mechanisms, but the general principle is to design mechanisms that make it possible to pay for services when they are provided. Kristov Atlas recently wrote an article that gives a more comprehensive description of this approach, and previously Justus Ranvier has written on this topic [8, 9, 10].

An important aspect of these approaches is that they do not seek to predict or dictate what resources should be restricted, or what the relative costs should be. They just provide mechanisms that allow markets to develop if and when they are needed. Currently nodes provide data to SPV wallets for free. If they continue to do so, there is no need to force SPV wallets to pay for this service. This could be sustainable if serving SPV wallets remains a very low-cost activity, or if businesses choose to provide this service as a loss-leader. But it is also possible that the market will evolve such that wallets pay small fees for blockchain data services, for more reliable service, or to subscribe to fraud alert services. Designers of the system should not try to predict the exact shape of this market, they should simply facilitate mechanisms that make markets possible if needed.

Future vision

Let’s consider Memo as an example. What if it grows to be similar in size to Twitter? Recently an analysis of this scenario was published on Yours.org [11]. This article was a very interesting thought experiment about what could happen if an application such as Memo were wildly successful. The conclusion was that if it reached Twitter scale, Memo could generate enough data to fill 1GB, or even Terabyte-size blocks. It’s not unreasonable to be concerned with this finding. Bitcoin Cash holds out the promise to be global sound money, and it would be a shame if this aspiration were displaced by other uses.

We should not simply extrapolate directly from current memo.cash implementation to a Twitter-scale Memo. If it does achieve Twitter-scale, other changes and improvements would also take place. Let’s imagine for a minute what this could look like.

Imagine several dozen competing Memo apps that people can use on their smartphones or computers. These apps would connect to specialized Memo servers that provide them with the necessary data. There would be hundreds or thousands of these servers, and competing software server implementations. Some of these servers could support the memo apps in exchange for small micropayments. Hobbyists could run Memo servers for free, and others could be funded with advertising (inserting “promoted” memos similar to Twitter). These Memo servers could connect to each other through a Memo-specific network dedicated to memo.cash transactions. Non-Memo wallets could basically ignore the memo-cash transactions if they so chose.

For miners, Memo transactions would be treated the same as any other fee-paying transactions. If the network is able to do sharding, perhaps Memo-specific shards could be validated separately, with proofs that monetary properties of the shard are valid. Miners could prune old Memo transactions so that they do not need to store the entire Memo record. For new Memos that need old data to be validated, the miners could receive the needed data from Memo servers. Perhaps these transactions would need a higher fee to provide compensation for the extra effort needed to validate them.

Other applications could also similarly leverage the blockchain without crowding out the sound money use case. Perhaps hundreds or thousands of different applications and services could coexist using the Bitcoin Cash blockchain as a secure censorship-resistant base.

The scenario I paint here is just one possibility. The shape that the network takes will be determined through future economic and technical developments. By avoiding prescriptive planning, and embracing a market-based approach, it’s likely Bitcoin Cash will evolve capabilities and uses that we can’t currently predict or even imagine.

Conclusion

Lots of work remains to be done, but by following market principles and embracing growth, there is no obvious scale limit. Using market principles, the costs of different use-cases can be borne by those users. Various uses of the blockchain should be able to coexist in harmony, without crowding each other out. Bitcoin Cash can be used to power hundreds or thousands of useful services, and at the same time become the best money the world has ever seen.