Block size limit has been a hot topic lately. Some parties invested in Bitcoin want to raise the limit urgently, and others have demanded a wait-and-see approach. One of the side tangents that arose from this debate was developer conflicts of interest.
This latter topic drew my interest in particular. While many technologists are averse to examining personal motivations behind technical discussions, I find such examination a useful heuristic in sorting through noise to find signal. There are many different visions for the future of Bitcoin, and those visions weigh heavily on the qualities of the system that people value or discount.
For example, if you envision Bitcoin as an incremental improvement on existing payment technologies, you are likely to emphasize transaction throughput and low transaction fees, and disparage the need for transactions to resist censorship.
If you are interested in Bitcoin as a mechanism of redistributing wealth, you may extol the virtues of the blockchain’s immutability, but downplay the sanctity of the 21 million supply cap and frown upon the proof-of-work mechanism as a “waste of energy.”
I share neither of these visions. Supporting them would not make a person’s technical arguments incorrect, but they do serve as meaningful guides when prioritizing which opinions to consider in a seemingly endless sea.
I also think that people who are not honest with how their vision for Bitcoin impacts their technical opinions are playing a dangerous game. This is a recipe for self-delusion and the unconscious manipulation of others. It encourages the mind to omit unflattering details when exploring the facts of our arguments, and leads to incessant moving of goalposts when these omissions are called out. If a contentious argument has lead people to take sides, dishonesty drives us to tow the party line, and refuse concession when our “comrades” are successfully rebutted.
The antidote is to be honest with ourselves, and open with others about our motivations. Challenges about personal motivations alone are rarely helpful, but we are hindered by pretending that they do not exist. When proposing changes to Bitcoin or refuting them, I think it is helpful to state assumptions such as:
- What version of Bitcoin would this change assist? Which version would it hinder?
- What attacks would this make easier? Which ones would it make more difficult?
Note that the latter line of inquiry presupposes a comprehensive threat model, which some good folks are working on1.
I made a mistake a few weeks ago in a tweet when I singled out a particular organization when opining about conflicts of interest. Leading up to the tweet, I had noticed some comments from employees at Blockstream that appeared to dismiss their potential for a conflict of interest. Blockstream has hired several core developers, at least some of whom contend that core developers must come to a total consensus on issues such as block size limit. Simultaneously, Blockstream is developing several technologies that emphasize transacting in spaces other than the Bitcoin blockchain; Lightning Network, in particular, is deliberately designed to decrease the demands put on the blockchain, and hence decrease the need for block size increases. Annoyed, I let fly a comment to the following effect: “When Blockstream denies a conflict of interest, it makes them look more guilty.”
There are a few things wrong with this tweet, but I want to focus on three in particular.
First, it did not successfully convey the original point in my mind: We should all be willing to openly discuss our investments and motivations in critical technical debates. It may have escaped my notice, but I haven’t seen anyone go out of their way to highlight their conflicts of interest in the block size limit debate, and Blockstream is but one organization out of many involved. For example, my employer’s primary products are APIs and Bitcoin wallet thin clients; the less convenient it is for users to access these services directly through the Bitcoin network, the more incentive they have to use services such as ours. Our business leans heavily on Mike Hearn’s BitcoinJ library. We clearly stand to benefit from bigger blocks. Likewise, if Lightning Network becomes a “caching layer” for Bitcoin on which the majority of transactions are performed, blockchain explorer APIs will need to adapt to a new paradigm in which the transactions taking place on-chain are much less meaningful to the average user. It’s not clear how that sea change would shake out, but it’s a new risk to existing businesses.
I’m hardly a significant figure in the block size debate, but the point is: all of us have a dog in this fight. Most have particular financial interests directly impacted by its outcome. For the few who do not, their vision for Bitcoin will still be impacted. Since I have not observed forthcoming from any party, it makes no sense for me to single out a particular one.
Second — and this speaks partly to why I and others have unfairly focused on Blockstream — I think they are to some degree being made victims of their own virtue. Bitcoin desperately needs development. Development needs time, passion, energy, and ultimately funding. Blockstream is one of the few companies that has encoded core development into its core business plan. They have managed to fund so many core developers that they now employ the largest contingent of them out of any organization at present. As a consequence of this prudence, they have become the most obvious to examine when exploring fears about how core devs’ incomes may conflict with their drive to reach consensus with the other devs.
Third, my tweet was not empathetic toward a cadre of hard-working, highly scrutinized, and sadly, often insulted technicians. It’s easy for people under those pressures to grow weary of that kind of negative attention. I have derived a tremendous amount of satisfaction playing and working in this space, and have extremely high hopes for the good that the technology will bring to the world. I owe those who have worked tirelessly on the project a debt of gratitude, and regret contributing to their frustrations with a community that can sometimes be ungrateful.
The exploration of motivations behind technical arguments should be a routine act initiated by the makers of the arguments. It should speak to the assumptions that underlie assertions, and should never resort to attacks on intelligence or character. We may not all be working toward the same Bitcoin, and that’s okay, because we are all competing in a marketplace of ideas. Let’s set aside argumentation tactics and let the ideas really speak for themselves.
1: See: “Increasing predicability [sic] and rigour with threat modelling” in the Bitcoin XT mailing list and “Bitcoin threat modelling thread” in the Bitcoin Dev mailing list.