Coindesk Logo

The Bitcoin Block Size Debate Isn't Just About Technology

The Bitcoin Block Size Debate Isn't Just About Technology

The Bitcoin Block Size Debate Isn't Just About Technology

The views of the Bitcoin Core developers are not the only ones that should count when deciding its future, says developer Elliott Olds.

The views of the Bitcoin Core developers are not the only ones that should count when deciding its future, says developer Elliott Olds.

The views of the Bitcoin Core developers are not the only ones that should count when deciding its future, says developer Elliott Olds.

AccessTimeIconFeb 7, 2016, 1:38 PM
Updated Aug 18, 2021, 4:33 PM

Presented By Icon

Election 2024 coverage presented by

Stand with crypto

There is a misconception in the bitcoin community that the roadmap for how bitcoin should scale is based almost entirely on the technical judgment of the Bitcoin Core developers.

While the Bitcoin Core roadmap does draw heavily on the substantial technical expertise of the Core developers, there are many non-technical factors that influence the Core roadmap.

Many people agree with Core on all of the technical issues, yet still disagree with their roadmap.

That's because the roadmap is based on assumptions about economics, group psychology, ethics and many other things which we have no reason to believe Core developers have any special skill in. The roadmap also depends on pure personal preferences.

Consider the following 10 questions:

  1. How much should it cost someone to run a full node? What’s the highest price we’re OK with?
  2. Does bitcoin have a social contract? If so, what is it, and how much weight should we give it?
  3. How should we trade off risks to decentralization vs other things? (Be sure to click through to both links if you find yourself upset by this question.)
  4. How likely is it that a smaller or larger block size limit will have any significant impact on Bitcoin’s adoption or price?
  5. How quickly will the costs of bandwidth/storage/computing power likely fall in the future?
  6. If we don’t need higher fees right now, should we still encourage them to avoid giving users the expectation that low fees can continue indefinitely?
  7. How important is the "fidelity problem" as described in this video by Jeff Garzik?
  8. How important is it to encourage adoption in the early stages of Bitcoin’s growth, because of money’s network effects?
  9. Are controversial hard forks a legitimate method of bitcoin governance? In this post, Greg Maxwell suggests controversial hard forks are close to theft. Others believe they are completely legitimate.
  10. How will users, businesses, and investors most likely react to a controversial hard fork?

These questions are very relevant to how bitcoin should scale, but they all depend on things outside of Core’s expertise.

To be clear, I am not suggesting that Core developers are worse than other smart people at thinking about the non-technical components of the above questions. The Core developers are very capable and have spent a lot of time thinking about the non-technical issues surrounding bitcoin, but so have many other highly intelligent people in the bitcoin community.

If Greg Maxwell, Pieter Wuille, and Wladimir van der Laan are in a debate about some predicted economic consequence of hard forks with Meni Rosenfeld, Jeff Garzik and Ben Davenport, we shouldn't give extra points to Greg, Pieter, and Wlad’s arguments just because they have the most experience working on Bitcoin Core.

With this in mind, what should we make of the claim that the Core roadmap has overwhelming consensus among Core developers, and that this is a strong signal that it’s the best plan?

The important question here is: "Are the Core developers the foremost experts on the actual issues that are driving the disagreement?"

To find the best path forward, we should consult the best experts in the areas where the controversy actually exists.

To take some simple examples, if the disagreement hinges on a technical issue in the Bitcoin Core code, then it’s reasonable to treat Core developers as the group of experts who should be consulted to determine consensus. However, if the debate hinges on a disagreement about the effect of higher fees on adoption or how important short term adoption is for bitcoin’s long term health, then we have no reason to restrict the group of those surveyed to Core developers.

The ideal group of experts in this case may include some Core developers, but only as a small part of the overall group whose views we consider.

During my observation of the block size debate, I’ve seen many highly intelligent people (including bitcoin developers who work on projects other than Core) who either agree with Core or are willing to defer to them on the technical issues, but who disagree with Core’s roadmap because of different views on the types of questions I list above.

We should not discard the views of these people when determining consensus on non-technical issues just because they don’t work on Bitcoin Core.

This piece originally appeared on Olds' Medium blog and has been republished with the author's permission.

Follow Elliott on Twitter.

Image via Shutterstock


Learn more about Consensus 2024, CoinDesk's longest-running and most influential event that brings together all sides of crypto, blockchain and Web3. Head to consensus.coindesk.com to register and buy your pass now.


Disclosure

Please note that our privacy policy, terms of use, cookies, and do not sell my personal information have been updated.

CoinDesk is an award-winning media outlet that covers the cryptocurrency industry. Its journalists abide by a strict set of editorial policies. CoinDesk has adopted a set of principles aimed at ensuring the integrity, editorial independence and freedom from bias of its publications. CoinDesk is part of the Bullish group, which owns and invests in digital asset businesses and digital assets. CoinDesk employees, including journalists, may receive Bullish group equity-based compensation. Bullish was incubated by technology investor Block.one.