Block Size Political Economy Follow-Up 1: Software Choice, Market Differentiation, and Term Selection
/An interview with me on the Bitcoin block size limit appeared on 4 May 2016 on Bitcoin.com. Below, I develop additional clarifications and examples partly inspired by a range of comments and reactions to it. This is meant to build on and develop ideas in the original interview. For ease of reference, here is a PDF version of that interview.
This is a three-part series. Part 1 below covers a range of issues including the need to differentiate the market that was discussed in the interview from other distinct markets and non-market choice phenomena such as free software selection. It also begins to discuss the use of the term market intervention in this context. Part 2 will then continue by arguing that neither the voluntary nature of cryptocurrency participation nor the subjective nature of user preferences nor any alleged motivations on the part of the various actors involved alters my analysis. Finally, Part 3 will focus on economic distinctions between the 21-million bitcoin production schedule and the block size limit, arguing that these are different in kind and thus poor objects for analogy.
Chicago Board of Trade: People buying and selling form a market. Prices are key artifacts that market processes leave behind.
Two markets and a non-market choice sphere
One idea that showed up in comments was that I had expressed some view as to which Bitcoin software one ought to run. However, I did not address this at all. I have only published one previous preliminary article on the block size limit, on 20 June 2015, and this also did not mention implementation choice. Various views on this topic do not alter my analysis of the topics that I did address.
A related idea is that the current dominant software implementation already reflects “the choice of the market.” Therefore, any discussion of differences between a cryptocurrency having or not having a given block size limit is moot: the “market” has already spoken and this is evident in implementation share statistics.
It should be cautioned, however, that software choice reflects many considerations. Interpreting it as a proxy for a single issue is imprecise. Such choices may well reflect a generalized confidence in perceived quality and reliability. A user could therefore make a particular software choice either: 1) because of one specific code issue, 2) despite that same particular issue, or 3) regardless of it.
Such imprecision and ambiguity are among the reasons I did not discuss this matter at all. A more fundamental reason, however, is that it has no bearing on my analysis. Whether some percentage of a given population prefers Pepsi or Earl Grey tea does not alter the composition of the respective beverages in the slightest way, nor their respective effects on metabolism. Such things can be studied and assessed independently of the current statistical shape of user preferences.
In addition, choice of which free software to run does not really constitute a market, except in a metaphorical sense. Developers offer software products and users select and run such products. In a free software context, nothing is bought or sold between these groups. No price signals exist directly between users and developers.
In contrast, the central topic I addressed—the market for the inclusion of transactions on the Bitcoin blockchain—is indeed a market, one that involves quite different roles and actions than producing or running one version or another of free software. This is a market in which bidders send transactions, which takers (miners) either include or not in each respective candidate block. This market involves specific senders of specific transactions (not senders in general of transactions in general). At the other end, specific miners build each of their respective candidate blocks. In deciding whether to include any, all, or some transactions, fee/byte (bid) is salient. Node operators act as key intermediaries, like referring brokers, currently uncompensated. On-chain and off-chain transacting options, both existing and potential, coexist in this context in a complex blend of competition and synergy.
There are therefore at least several phenomena to differentiate. First, the buying and selling of bitcoin forms textbook markets on the order of commodities and forex markets. Those effectively controlling given bitcoin units can sell such control in exchange for some other money unit, product, or service, or give them away as gifts. Second, bidding for on-chain transaction inclusion and miner decisions to include or not include transactions in candidate blocks forms a distinct open-bid market for on-chain inclusion priority. Third, developers offering free software and users making decisions on which implementations to run for their various purposes does not constitute a market in the sense of a complex of buying and selling behavior.
Whatever one may choose to call these three phenomena, each is meaningfully distinct from the other, describing different sets of actions and roles. To claim that “the market has spoken” in the context of software choice is therefore far less informative that it might at first appear to be. Making such a claim requires specifying what exactly has allegedly spoken (it isn’t a market) and the content of this purportedly speaking thing’s alleged message (ambiguously mixed with considerations such as general perception of code reliability).
The term “market intervention”
Several commenters took issue with my use of the term market intervention in this context. It is true that market intervention has a negative connotation for many readers, though not all. Indeed, a great many persons eagerly advocate some form of governmental intervention in economic affairs as part of their ordinary political opinions. Still, one interpretation would be that I had set out to create negative connotations and thus arrived at my word choice using rhetorical criteria.
A different interpretation would be that I set out to select the most accurate available technical term to describe the phenomenon under consideration. I then specified what I meant in using this term and excluded certain inapplicable historical and institutional associations. This is my own first-hand interpretation of what I did in selecting this language. That it still has negative connotations for some may be natural in that what it describes has negative effects. However, word choice one way or another does not alter such effects.
Another related but more substantive criticism that appeared in several variants argues that a block size limit is just a qualitative characteristic of a cryptocurrency as a good. A given limit is baked into what the good is. As such, it cannot be construed using the model of economic intervention. If a characteristic is already in the product, how could it possibly be construed as intervention (from outside)?
However, I had already stressed in the interview how novel and unprecedented this situation is. My argument was that even though the legal and practical contexts of traditional interventionism conducted by state agencies are completely different, nevertheless, the economic effects are on this transaction-inclusion market as a government enforced industrywide output ceiling would be. This will be addressed further in Part 2.
A commenter suggested that I was arguing from history that the current block size limit was not part of “consensus.” Consensus, in this debate, often seems to transcend a mere computer science fact to also encompass an allusion to a hard Bitcoin Realpolitik. Any other considerations, such as the documented history of the block size limit, are irrelevant to this current reality.
However, I did not reference or use any concept of consensus at all. Nor did I question the reality of any given state of consensus on the network at any given time. What I did was analyze differences between possible states of code and then describe economic and social implications of such differences.
A loosely related idea was that my analysis was tantamount to advocating that cryptocurrencies should not maintain any limits or standards. If calling into question one sort of limit, such as the current Bitcoin block size limit, why not just question all limits? Why not just also advocate raising the maximum coin count? That, after all, is also a “limit,” so why not call keeping that in place an “intervention” too? This will be addressed in greater detail in Part 3.
The interview itself concerned one such limit and not any others. Why? I could have branched off to discuss the sociology of decision-making or described a software preference. But I did no such things. I could have discussed any other protocol characteristic or issue. Why did I discuss only this one? The answer is that I think this limit has unique economic features that are both important and poorly understood. Explaining this was therefore the focus.
Continues with Part 2.
