<img src="https://d5nxst8fruw4z.cloudfront.net/atrk.gif?account=qmvEl1aAFUE06C" style="display:none" height="1" width="1" alt="" />
Bitcoin Price $629.02 Hash rate 1.60 Exahash

NOW READING:

On Consensus, or Why Bitcoin's Block-Size Presents a Political Trade-Off

by: Aaron van Wirdum

On Consensus, or Why Bitcoin's Block-Size Presents a Political Trade-Off

Bitcoin’s block-size dispute rages on. A proposed change to a single parameter in Bitcoin’s reference implementation has spawned into a great debate, resulting in tireless discussion, multiple conferences , a growing split within the Bitcoin community and at least one prominent developer joining a bank-run alternative.

The subject of debate itself, moreover, started out in the technical realm, predominantly relating to the increased propagation time of larger blocks, and the level of mining centralization. Over the past year, however, the same debate mostly moved into the political domain, leading to the big question of governance, and the spawning of several competing Bitcoin implementations.

But interestingly, these two domains – the technical and the political – are not necessarily separate. Not only do some technological trade-offs require political decision-making, political decision-making can sometimes be influenced by technological trade-offs.

The block-size limit provides an outstanding example.

Social Implications of Technology

A widespread belief within the Bitcoin community (often employed to excuse the currency’s notorious use on darknet marketplaces) is that all technology – including Bitcoin – is neutral, and can be made to serve various ends. Like a hammer, which can be used to build a house or bust someone’s scull, Bitcoin is claimed to be detached from ethics: a mere means. Some even follow this argument to conclude that Bitcoin’s block-size limit must be raised simply because there is demand for increased transaction capacity, as if a dictate by some force of nature rather than a conscious decision.

But this neutral perception of technology in general, and of Bitcoin in particular, is false. Design choices can greatly impact what a technology is used for, and especially when made in the early stages of a its development.

To illustrate this, let’s explore the evolution of another technology: the bicycle. Shortly after the bicycle was first invented in the late 19th century, initial designs started out as two quite different devices. There was the sportsman’s racer for people who perceived bicycling as a competitive sport, which had a high front wheel that was fast but unstable. And there was the bicycle as a utilitarian means of transportation for people who simply wanted to get from A to B, which had a safer two equal-sized low wheels.

The utilitarian bicycle eventually won out. This shifted the energy invested in research and development toward this design, after which it benefited from all subsequent advances in the field of bicycle technology. In retrospect, it may seem that high wheelers were a clumsy predecessor to the modern bike, but in reality the two designs co-existed and competed. Rather than an early stage of the bicycles we know today, the high wheeler represented a possible alternative path of bicycle development, which would have addressed very different problems.

The bicycle example is probably an innocent one. But what if the various technical solutions to a problem have different effects on the distribution of power? Then the choice becomes political. And – importantly – the political implications of that choice will be embodied in the technology.

One telling example of such a choice were the plans for a New York expressway, designed halfway through the 20th century by well-known city planner Robert Moses. This particular expressway included overpasses that were too low for city buses. As such, the lower class from Manhattan who depended on bus transportation – in large part the African-American population – was discouraged from visiting the beaches on Long Island. A simple design specification contained a racial and class bias.

Now let’s see how this notion applies to Bitcoin’s block-size limit.

Consensus Rules

Bitcoin’s block-size limit is one of Bitcoin’s consensus rules. These consensus rules are an incredibly important set of rules. Besides the block-size limit, they include, for instance, that the block reward halves every four years (each 210,000 blocks), which limits the total amount of bitcoin to 21 million. They also include that all bitcoin used in a transaction must have a traceable origin (save for the mining reward), preventing users from creating bitcoin out of thin air. And they include that blocks must be created at the required difficulty setting, making sure miners can’t enrich themselves for free.

Bitcoin’s consensus rules are checked by full nodes. Full nodes are Bitcoin implementations that receive transactions and blocks from other full nodes, and verify whether these adhere to the consensus rules their operator installed. If these transactions and blocks check out, transactions are typically forwarded to other full nodes, and blocks are added to the blockchain. (And if a full node is operated by a miner, it will also use valid transactions and blocks to find new blocks.)

But if the transactions and blocks a full nodes receives do not adhere to the consensus rules its operator installed, they are considered “not Bitcoin” by that node, and are discarded. Moreover, all subsequent blocks any miner might build on top of that block are discarded as well.

This is crucial to understand, as it means that – contrary to popular belief – full nodes do not automatically follow the longest chain of blocks. Rather, full nodes automatically follow the longest chain of blocks they consider valid!

But this also means that two groups of Bitcoin users using different consensus rules could effectively create two different and incompatible blockchains. Each group would simply consider the other blockchain “not Bitcoin.”

To prevent such a split (a “hard fork”), the consensus rules among all full nodes must – indeed – be in consensus.

Full Nodes and Democratic Empowerment

The operator of a full node, and only the operator of a full node, decides which consensus rules that full node applies. As such, full node operators decide what kind of transactions they want to accept and, therefore, what kind of Bitcoin they want to use. Full nodes grant individual autonomy to their operators.

But operating a full node is not only empowering from an individual perspective; it’s also empowering in a more democratic sense, as full nodes carry out social influence through network effects . Full node operators are incentivized to apply the same consensus rules as other full node operators, since that allows them to transact. So, as a full node operator decides to use a specific set of consensus rules, the incentive to adhere to these consensus rules becomes stronger for everyone else, too.

This social influence can currently be witnessed by the fact that some full node operators would individually prefer to increase the block-size limit to produce and accept bigger blocks – but don’t.

Of course, Bitcoin’s consensus rules are not set in stone. While network effects make them hard to change, and no full node operator can be forced to, it is possible to make a (near) networkwide switch, providing a strong incentive for all full node operators to join the new consensus rules. Methods such as programmed into Bitcoin XT, allowing full node operators to signal they will make a collective switch in advance, could potentially smoothen this process. Innovations such as proof-of stake voting and prediction markets might improve it even more.

Users

Not all full nodes are equal from a network perspective. Rather, the weight of each full node is essentially carried by whatever it has to offer the rest of the network.

Full nodes operated by miners, for instance, potentially offer a lot of security through their hashing power. Full nodes operated by Bitcoin exchanges, payment processors, wallet services and other consumer-based companies, typically offer easy access-points to Bitcoin. And full nodes relying on software that is actively developed and maintained by prudent and trustworthy developers carry a lot of weight through the security they offer.

Miners, companies and developers all add weight to a set of consensus rules through the full nodes they run and support. But their influence should also not be overstated.

What it’s really about in the end, are all of the bar owners selling beers, immigrant workers sending the fruits of their labor home, citizens escaping inflation or currency controls, investors diversifying their portfolio, and – yes – even dealers on the dark Web selling drugs. Without them, miners could not get rid of the bitcoin they mine, companies would have no customers and developers would write code sitting idly on their computers.

Users ultimately give Bitcoin value.

The Trade-off

While Bitcoin users ultimately give Bitcoin value, miners, companies and developers are more likely to operate full nodes than users. And as the cost of running a full node increases, this likelihood increases, too.

This presents us with a trade-off.

Bitcoin’s block-size limit limits the amount of possible transactions on the network, which increases confirmation times, or the required transaction fees, or both. As such, it decreases Bitcoin’s utility as a payments system, which could slow down or restrain adoption. This could even limit Bitcoin’s potential as a widely-used technology – or require more complicated solutions to realize that promise.

But Bitcoin’s block-size limit is probably also the single most important parameter controlling the cost of operating a full node. It limits the required CPU cost of verifying transactions, it limits the bandwidth cost of sending and receiving transactions and blocks, and it limits the disc space cost of storing the blockchain.

And importantly: Bitcoin users who would like to run a full node but can’t, are excluded from Bitcoin’s consensus process. Above a certain size, increased block-size limit would allow a smaller percentage of users to directly influence the consensus rules.

Under such circumstances, rather than empowered participants of a networked consensus process, many worry that Bitcoin users could increasingly become consumers of a product offered by the few entities able to run and support full nodes; miners, companies and, arguably, developers, too.

Bitcoin users could still choose which full node operator they hand their “vote” to, for example by using bitcoin mined by a specific set of miners. Or they could use a company that supports the same consensus rules they do. But this requires trust, and only makes sense if there is at least one full node operator supporting the consensus rules a user desires. (Regulation of companies, and in a very centralized scenario of full nodes themselves, might even completely prevent that.)

The block-size parameter, therefore, embodies a certain type of politics.

The Current Status of Empowerment

Running a full node is currently burdensome , and perhaps in particular for “the other six billion ”: Bitcoin users in developing countries. This is evidenced by the rapidly falling full node count over the past years.

But many Bitcoin users could probably still run a full node if they’d want to.

This means that even if a super-majority of miners, companies and developers all decide they want to increase the block-size limit, most users could still oppose such a change by firing up a full node and keep applying the existing consensus rules. And since Bitcoin is really carried by its users, a super-majority of miners, companies and even developers would have to cease their efforts – or make themselves obsolete.

Users are effectively still in charge.

Moving Forward

In search for guidance on the best way to move forward, both sides of the debate tend to refer to either Satoshi Nakamoto’s writings, or Satoshi Nakamoto’s perceived vision, or both. But apparent contradictions within, and alternative interpretations of, the Bitcoin creator’s white paper, emails and forum posts have deemed this practice fruitless – probably even divisive. And if we are to take his words literally, both sides of the debate seem out of line. We should, therefore, perhaps instead accept that Satoshi was fallible, that his writing are not scripture, and that he could not foresee the state of Bitcoin years down the road.

Instead, in order to move forward, we should probably apply our own reasoning to the best of our abilities.

There is, of course, nothing inherently wrong with the vision of Bitcoin users as consumers, rather than direct participants in a consensus process. Judging by proposals, articles, and comments by several miners, company executives, developers, and regular users, many are OK with such a future, and consider market forces sufficient to offer a desirable user experience for all.

But users, in particular, must realize that an increased block-size limit could increase the cost of directly participating in the consensus process. And, of course, that this process is not limited to the block size limit itself – it also covers all other consensus rules.

Additionally, everyone should understand that increasing the cost of partaking in Bitcoin’s consensus process too much might not only exclude their future selves from partaking in that process. It could also exclude users currently unable, as well as future Bitcoin users, from ever partaking in Bitcoin’s consensus process in the first place.

There is nothing inherently wrong with the vision of Bitcoin users as consumers rather than direct participants in a consensus process – as long as everyone understands that the trade-offs are not just technical, but also political.

The first part of this article is based on Andrew Feenberg’s Questioning Technology .

Thanks for suggestions go out to Jan Overwijk, PhD Candidate at the University of Amsterdam. Additional thanks for proofreading to Bitcoin Core developer Peter Todd, Ulterior States producer Tomer “IamSatoshi” Kantor, Bitcoin Unlimited contributor “Veritas Sapere,” and Bitsquare developer Manfred Karrer.

Thank you!