Kristov Atlas is a network security and privacy researcher who studies cryptocurrencies. He is currently a security engineer for bitcoin wallet provider Blockchain and co-founder of the Open Bitcoin Privacy Project.
In this opinion piece, Atlas discusses bitcoin's ongoing block size debate, arguing that the economic analysis of potential changes to the system has been largely ignored by network developers.
As many writers have proffered their short-term suggestions for addressing bitcoin's transaction throughput, I’d like to take a step back and explore how we think about, discuss, and plan the future of bitcoin.
To date, much of the discussion around Bitcoin’s scalability has suffered from two major problems:
- We lack a systematic process to set and achieve goals with respect to security, censorship resistance and the overloaded term "decentralization".
- We have a poor understanding of the relationship between engineering decisions and their economic consequences ("cryptoeconomics"). By "we," I mean myself foremost, but I can fairly include many stakeholders in the ecosystem including some protocol developers, wallet providers, miners, exchange operators, writers, and enthusiasts.
Because we lack these tools, we are ill-equipped to make protocol decisions and to plan bitcoin's software future.
In this post, I’d like to focus on the second deficit in the list: economics.
What is crypto-economics?
I define crypto-economics as the study of the production, distribution and consumption of goods and services in cryptographic consensus networks. In particular, it is the study of the economic implications of cryptographic design choices in such networks (like bitcoin).
For example, suppose you created a cryptocurrency that did not have a predetermined supply algorithm for the currency units, but was instead determined on a month-to-month basis by majority vote among a few human keyholders.
How would this system compare to bitcoin?
Another example. A wallet client sending a bitcoin transaction must communicate the transaction data to bitcoin miners to be included in a block. What incentive do uncompensated nodes have to relay this data from the client to a miner?
These are questions for cryptoeconomics.
The snooze button
First, I want to acknowledge that economics, like other fields of study, can be very boring. I can appreciate those who would prefer to avoid the topic and focus on other aspects of cryptocurrencies. These systems are so complicated that, less than a decade after their birth, we require specialization.
I would recommend, however, that avoiders of cryptoeconomics get a taste, simply so that they can remain aware of the boundaries of the subject they wish to avoid.
Austrian economist Murray Rothbard said this best:
Economics, to date, has been a very odd realm of study. It is a study of human action, but one conducted by a society deeply in denial about the profound impact of a few economic planners on the decisions of the many.
Economists are like doctors of medicine charged with studying and optimizing the health of a room full of lepers, and then advising the rest of the world on how best to maintain health.
The minority of economists who have dared to challenge preconditions of central planning have had few opportunities to test their theories because there is nowhere in the world to find humans who trade in its absence. This long-standing state of scientific befuddlement has damaged technologists' trust in the study.
Still, economists have had several centuries to construct basic principles and models of economic interaction, such as the laws of supply and demand, elasticity and marginal utility.
Although the many hours wasted by economists on how best to direct the power granted to human central planners will be useless to bitcoin, many of the fundamental principles of economics will act as lighthouses in efficiently allocating resources in bitcoin.
Bitcoin creator Satoshi Nakamoto set a powerful precedent for bitcoin by making economic thought a centerpiece of its design.
For example, Satoshi improved on the design of fiat currencies by establishing a predictable currency supply. However, he also created many points of economic rigidity into the initial design.
These points of rigidity have worked well enough, but will increasingly reveal themselves as the number of participants in the system grows. One of the points of rigidity, introduced as a temporary security mechanism, has been repurposed as an economic control. In spite of Satoshi’s legacy of holding economic considerations as a primary value, this has not persisted with all of his successors.
Prior to 2009, practically everyone in history who made decisions about the design of other people's currency arrived there through a political process.
Bitcoin was the first successful software project that allowed economically meaningful interaction according to rules set in an open-source software ecosystem. This advent is not just an opportunity — but a mandate — to apply free market principles to software consensus rules.
Other currencies can compete with bitcoin at a historically low cost; any currency that fails to apply efficient market mechanisms will underperform and eventually become defunct.
The calculation problem
Markets perform worse when a few people try to allocate resources for a large number of people against the larger group's will.
This was described by Austrian economist Ludwig Von Mises as the Economic Calculation Problem. Mises, and his successors such as Friedrich Hayek, reasoned that the economic value of goods and services are best estimated using market prices, and that bureaucratic or technocratic methods cannot rationally allocate resources.
This means that when we put bureaucrats in charge of allocating goods like clothing, computers and food, we end up with uglier clothes, slower computers, and more expensive food.
Likewise, a crypto-currency designed purely through technocratic means will have worse transaction throughput, less scalability, inferior security, and be valued at a lower price.
In this latter context, central planning occurs not when some minority of humans sets rules that the majority of humans must follow — humans are always able to choose not to use bitcoin, after all — but when developers set constraints on the allocation of resources and services. We should pursue the alternative whenever possible, to allow market mechanisms to determine prices and to allocate resources according to this information.
Here’s a simple example of protocol central planning that would become disastrous quickly.
Imagine that bitcoin developers imposed a specific number of transactions that must go into every bitcoin block (eg 100 transactions per block) and a fixed transaction fee (eg 1 BTC).
In this scheme, until the network accrued 100 transactions worth of demand, no blocks could be mined, leading to even less predictable time intervals between blocks than today's bitcoin. If users wanted to send more than 100 transactions in a given period, they’d be out of luck, and would have to wait until demand died down enough to squeeze in.
Since fees would be fixed at 1 BTC per transaction, users with different preferences on confirmation times would not be able to negotiate higher or lower fees for their individual transactions.
Lastly, as the price of 1 BTC would likely fluctuate relative to other currencies, transaction fees would rise and fall according to the currency's speculative value at the time, rather than responding to supply and demand for space in blocks. In the best case, this system would only support about 5 million transactions per year, with transaction fees of 5m BTC per year. It would not be a very useful system, regardless of whether the majority of stakeholders approved of this design.
Luckily, today’s bitcoin is so much more economically flexible that it would soundly defeat this hunchback of a currency.
Still, bitcoin developers are routinely tempted to respond to protocol challenges with central planning. In early 2013, a bitcoin security researcher disclosed a way for an attacker to create a transaction that would take extraordinary long for most nodes in the network to validate.
His first suggestion was to centrally plan the maximum size of a bitcoin transaction with a soft fork change to the protocol’s consensus rules. When you are in a position to centrally plan, it’s always the fastest and simplest way to address a problem.
Central planning of the consensus protocol has parallels to the phenomenon referred to as "centralization" in the bitcoin ecosystem in that both represent the path of least resistance in the short term.
It is much simpler to create a bitcoin bank than to craft a real wallet or decentralized exchange; a bank website is comparatively simple and familiar to us, permitting a lot of conceptual recycling and requiring little innovation, even if it comes with much greater security and censorship-related risks.
In the future, I would like to see the bitcoin community adopt these two values:
- Economic research should be considered seriously and responded to. For example, if we make design decisions to create a fee market, and an economist writes a paper presenting strong arguments for why a fee market already exists, later supported by additional empirical data, this must be processed. If we introduce a constant to foster economic health of a service in the system (mining) and someone rightly points out this is a type of economic control with a deeply problematic past, we must revisit this approach and consider other options. Economics should not be treated as a second-class citizen to computer science, but should be considered in tandem.2. We must seek to eliminate points of central planning in the design of bitcoin. When we do introduce such controls, they should be acknowledged as suboptimal and temporary, and ideally with a concrete plan for their removal. While it is tempting for the most influential regime in the ecosystem to use economic controls to pursue their goals, they should remember that they will not always be the most influential. It is imperative that we encode resistance to economic central planning in bitcoin’s DNA, not only to help it perform efficiently in the present, but also to protect it from the temptations of its future caretakers. When central planning simply represents the "path of least resistance" to a problem, we should acknowledge this as a form of technical debt that will need to be resolved later on.Neither of these values will be easy to adopt. Crypto-economics is a new field with few or no established authorities. Protocol security is challenging even when largely ignoring economics. Weighing two concerns with our currently limited models is going to be difficult, and it will take a lot of work to elevate such comparisons from the realm of expert intuitions to a structured system of thought.
At first glance, it might appear that security and economic efficiency are at ends. I don’t think so. These considerations are intertwined in many ways. A consensus system with poor security has little economic value; likewise, a consensus system with low economic efficiency is not worth securing.
Difficult as it may be, there's no real alternative.
Most of the best minds in the crypto-currency space work in bitcoin, but the advantages provided by a superior engineering talent pool can only overcome the disadvantage of market inefficiency for so long.
This article originally appeared on Kristov Atlas's website, and has been republished here with the author's permission.
Landscape photo via Shutterstock
The leader in news and information on cryptocurrency, digital assets and the future of money, CoinDesk is a media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. CoinDesk is an independent operating subsidiary of Digital Currency Group, which invests in cryptocurrencies and blockchain startups. As part of their compensation, certain CoinDesk employees, including editorial employees, may receive exposure to DCG equity in the form of stock appreciation rights, which vest over a multi-year period. CoinDesk journalists are not allowed to purchase stock outright in DCG.