read.cash is a platform where you can earn money for your articles and comments. You can get paid upvotes
from other users or just earn points for writing articles and comments, which are converted daily to
Bitcoin Cash (BCH) cryptocurrency, which can be used on the Internet or converted to your local money.
Over the past few weeks, the Bitcoin Cash community has been struggling to find appropriate language and analogies to describe the "Infrastructure Funding Plan" (IFP). Some have seen it as a clever way of leveraging the difficulty-adjustment algorithm to help out underfunded sectors of the BCH infrastructure. Others have described it as a "miner tax" or a "dev tax", and have raised various objections regarding the way recipients are chosen for these partial-block-reward funds.
For now, the IFP proposal appears to have encountered enough push-back that it will probably not come into effect. However, a hidden division still exists in the community. On one side are people who feel that the idea of allocating a portion of block-rewards towards infrastructure funding is basically a good idea. They acknowledge that it may need some careful execution. For example, the plan may require some kind of voting system to decide who actually receives the funds. But in their minds, there is nothing wrong in principle with the idea of setting aside a portion of all block rewards to fund projects that benefit the whole ecosystem. On the other side, there are people who feel that the idea is fundamentally flawed. In their view, no amount of careful planning or checks-and-balances will be sufficient to make sure that the partial block rewards are distributed fairly. To the extent that donating partial block rewards is a consensus rule, there must be some addresses that are not eligible to receive the funds. If a miner submits a block with the infrastructure portion allocated to a non-approved address, other miners will have to reject the block. If this does not happen, then the consensus rule is meaningless, because the miners could simply nominate their own address as the recipient of the infrastructure funding. Because of this, many people think that any such plan will inevitably create a political struggle over who controls the list of acceptable donation addresses.
This division is unhelpful. At some point, one group is going to propose an amended version of the IFP, one which they feel has resolved the execution mistakes of the first attempt. At that point, the opposite group is going to complain that the concept of the IFP is still fundamentally misguided. In the first round, both sides were able to agree to delay the debate for pragmatic reasons, because putting it off was better than risking a chain-split. But when the idea resurfaces in a more nuanced form, the mere presence of controversy will no longer be enough to get both sides to agree not to implement it.
Rather than wait for that to happen, a better approach would be to go back to first principles, to understand as a community what the IFP really represents at an economic level. Two of the greatest strengths of the Bitcoin Cash project are its foundations in Austrian economics, and its culture of libertarianism. In this article, I want to get us back to those roots, and explore the IFP through the lens of private property and the non-aggression principle.
John Locke proposed a theory of private property (later elaborated on by Murray Rothbard), in which objects in the "state of nature" pass into private ownership once a particular individual "homesteads" them by applying his will to transform them into a non-natural state. A meadow is in the state of nature, just as nature left it. But a field is private property, because its owner has applied their labour to plough the field, plant it with crops and organise it into a more useful state than the state in which it was left by nature. This is the origin of all genuine property rights.
How then do we apply this theory to block rewards, which are gained through Proof-of-Work mining? Well, the first thing we must notice is that the property rights to the block rewards (and all transaction fees) for a given block must necessarily belong to whoever did the mining. The block was created through the mining process. It was the miner who did the work to "homestead" the block reward, and therefore the fruit of that labour is the miner's own property.
But what about other people who were involved in generating the BCH blockchain? Does their labour entitle them to a portion of the block rewards? The miners may have run the ASIC hardware, mining pool nodes, etc., but they generally don't write the node software themselves. The miners would never be able to mine a block if the node software was not written, so doesn't that mean that part of the labour that ultimately produced the block was the labour of the developers?
The short answer is: no.
The labour of the developers to write the node software does not give them any property rights over the block reward which was produced by running that software.
But our intuition from other areas of life shows that developers of software tools generally do not expect any royalties from profits earned by running their software. Novelists who use Microsoft Word to write their books do not pay royalties to Microsoft on each copy of their novel that is purchased. Photographers who use Photoshop for editing do not pay royalties to Adobe for each printed photograph that they sell.
Of course, there are exceptions. Game developers who use the FMOD audio library can download it for free, but they are required to pay a fee for each game they produce with it (https://www.fmod.com/licensing). There is nothing wrong with this business model. Adults can enter into whatever contracts they wish, including a contract that involves paying royalties on sales of products made using certain software. But the fact of the matter is that Bitcoin mining software (including Bitcoin ABC) is generally not released under any type of royalty contract.
So, to what exactly are the developers of node software entitled? They are doing useful work, producing useful software that did not previously exist, so they must be homesteading something. The answer is that they are homsteading the licensing rights over the software that they produce. The developers could choose to release their mining software under a different license, one which did require the miners who use it to send a portion of any block rewards to the developers. The developers would be within their rights to do this. Indeed, if their mining software tended to produce twice as many blocks as competing mining software, most miners would be happy to pay a 5% or 12.5% cut of the block rewards to the developers, because the miners would still come out ahead.
Of course, this is all hypothetical. The developers of Bitcoin ABC have released their node software under the MIT license. What users do with the software is their own business. If a user mines BCH blocks with it, the rewards from those blocks belong to the miner. The developers do not homestead the block rewards. The developers only homestead the licensing rights for the software.
One question that has been hotly debated is whether the IFP constitutes a form of "tax". Taxation is a tricky category, because it can cover so many nuanced arrangements. Tarrifs, excises, rates, sales taxes, income taxes, poll taxes, etc. The IFP is a unique arrangement. Because it is so tied to the concept of a "blockchain" and a "block reward", it is difficult to find good analogies to describe exactly how the IFP works, and who ends up paying whom.
However, one thing that should be clear is that the IFP can only be considered a tax if it involves coercion. That is, the IFP is not any form of tax unless it involves the threat of violence against someone, or plundering their property. So then, is there any threat involved in the IFP?
I confess, during the early stages of the debate, I would have said "yes, the IFP is coercive". But upon further reflection, I have come to see that I was mistaken.
On a strict definition, the IFP cannot be considered coercive, and therefore cannot be considered a "tax". The IFP simply does not involve any threat against anyone's person or property.
At first, I thought that the IFP did include a coercive threat, because it involved deliberately orphaning blocks. I reasoned that the miners who had mined those blocks had a property right to the rewards from those blocks, and their reward was getting stripped away from them when their blocks were orphaned. But that is simply not true. The block reward for an orphaned block still exists, and it can still only be spent by using the private key of the person who mined it. The block reward has not been "stolen". Rather, the block reward for an orphaned block now simply exists on a forked chain with minority hash power. If my block is orphaned, I can still choose to keep mining on top of it. No one can prevent me from doing that. If I mine a new block on top of it, that block can include a transaction sending my block reward to someone else. All of this still works. The only difference is that I am no longer following the chain with the longest Proof-of-Work, and the market has decided to value coins that exist on the longest-PoW chain dramatically more than coins mined on a minority chain (for good reason). My block reward is not stolen. My block reward is simply rendered dramatically less valuable by supply and demand on the free market.
So then, orphaning blocks, even deliberately and arbitrarily, is not a violation of property rights. If your block is orphaned, you still own your private keys, and you still own the block rewards for blocks you mined (even if the prevailing market value of those block rewards has massively declined).
Another element of the IFP proposal that has angered many people is the inclusion of specific addresses in the source code of the Bitcoin ABC software as "valid" addresses for IFP donations. To many people, it seemed as though this move was "forcing" miners to give funds to specific individuals and groups chosen by the Bitcoin ABC developers. But it is important to understand that publishing software can never be "coercive" in the strictest sense.
No one is obliged to run the latest of Bitcoin ABC release on their node or in their mining operation, simply because ABC has published it on GitHub. Node operators and miners are free to switch to any of the other node implementations, to edit the source code of the Bitcoin ABC client to suit their own preferences, or to keep running the previous version of the Bitcoin ABC client. No threats of physical violence are made against them if they do any of these things.
Now, that is not to say that publishing whitelisted addresses in the source code does not cause any problems. It does.
First and foremost, it is generally in the interest of miners and node operators to run node software that is "in sync" with the rest of the network. To do that, they have to know what changes other node operators have made to the node software for their own systems. A very simple way to achieve synchronisation is to simply download the node software published by particular developers and run it "as is". It is very easy to understand what changes other node operators have made to their node software if the number of changes they have made is zero.
By creating a situation in which miners and node operators are not content to run the software "as is", the developers are making the node operators' and miners' goal (synchronisation) more difficult to achieve, requiring more work on their part. But again, this is not strictly coercive. If I run a bakery, and I decide to move my operation a mile down the road for cheaper rent, I may have just created a situation where my customer has to pedal a bicycle two miles further each day to buy bread. In a sense, I have created work for him. But it was my right to move my bakery, and it is his right to go to a competing bakery if I am now too far away and I am no longer offering him the best deal.
Ultimately, no code commits that Bitcoin ABC publishes under an MIT license can ever coerce anyone into running the software against their will. The worst that Bitcoin ABC can do is create a market situation where the costs of synchronising node operations across the network are higher, which increases market demand for competing sources of node software, sources that require less effort to synchronise (i.e. Bitcoin Cash Node).
How then can we describe the IFP? What analogy can we use to help us understand whether or not it is economically beneficial?
I suggest that the IFP is best understood as a form of boycotting.
Boycotting is not "coercive" in the strict, libertarian sense. Consumers are within their natural rights to boycott a product or service for any reason. That is, they are within their rights to refuse to engage in any market transaction that they do not like. But market transactions, by definition, are mutually beneficial. Market transactions do not occur unless both parties believe they will be better off after making the exchange. When I buy bread from you, it is because I value the bread more than the money, and you value the money more than the bread.
By its very nature, boycotting reduces the total number of market exchanges taking place within the society. Therefore, boycotting necessarily makes the society poorer in economic terms. However, there can be good reasons for enacting a boycott. Namely, boycotting can be an effective tool for censuring someone. The decrease in economic output caused by a boycott is not evenly distributed. If everyone boycotts Mr. Jones' grocery store, then Mr. Jones will quickly go out of business. Everyone else will suffer a slight loss, since they will have one less choice available to them when they go looking for a store in which to buy their groceries. But Mr. Jones will suffer a much greater loss by losing his grocery store business. If Mr. Jones is known to make racist comments to any Ruritanians who enter his store, a boycott would be an effective way to punish him for this bad behaviour without violating his right to free speech, or any of his other rights.
The IFP has the effect of a boycott, because it amounts to a refusal to engage in market transactions with miners who keep the entire block reward for themselves. Those miners' behaviour is within their natural rights, the block reward is theirs to allocate as they see fit, because they are the ones who did the work to "homestead" the block. But node operators and miners who implement the IFP are showing their disapproval of the non-IFP miners' refusal to donate funds to approved infrastructure projects. As a result, pro-IFP node operators and miners choose to "boycott" those non-IFP blocks. Pro-IFP miners will not mine on top of those blocks, and therefore will not process transactions that spend the block-reward from non-IFP blocks.
This boycott action does not violate the non-IFP miners' rights. No one can force anyone else to mine on top of any particular block, or use any particular set of consensus rules. But the boycott action does reduce the total set of market transactions occurring in the BCH network. Effectively, those who participate in the boycott are economically cut off from those who refuse to boycott. If they each end up transacting on separate, incompatible chains, then they have reduced the total number of people with whom they are able trade, ultimately making everyone poorer.
The case for engaging in a boycott must always be based on some long-term gain that comes at the expense of a short-term loss for those who participate in the boycott (because they cut themselves off from certain opportunities for mutually-beneficial exchange). In this case, the long-term gain hoped for by the IFP boycott is that BCH infrastructure development would become better funded, increased development would allow the network to better serve consumer preferences, usage of the network would grow, and the value of the coins would ultimately increase.
A much-discussed feature of the IFP is that it doesn't decrease profitability for miners if all the miners participate. Instead it decreases the total hash-power dedicated to securing the BCH chain. But since the decrease in hash-power is thought to be fairly negligible in the present context (given that BCH hash-power is dwarfed by BTC hash-power), it is argued that this is a very beneficial trade-off to make.
For the sake of argument, let us assume that this assessment is accurate. Let us assume that implementing the IFP would not cause miners to make any less profit (in fiat terms), and users of the BCH chain would not suffer any noticeable loss from the decrease in hash-power securing the chain. Would that make the IFP a no-brainer?
As it stands, the IFP would require directing a fixed percentage of block rewards to a specific set of people. Whether that group is selected unilaterally by a whitelist included in the source code, or by some kind of voting mechanism, it would still be allocated at a set rate. If the recipients are unilaterally whitelisted, then the moral hazard is obvious: the whitelisted participants would not have to do any ongoing work in order to keep receiving their cut of block rewards. This creates an incentive to maintain political control over the whitelist, but creates no strong incentive to actually improve the software.
A voting mechanism is a little better, in that it would force development teams and other infrastructure projects to compete for the block reward portions. There would be some implementation pitfalls around preventing miners from colluding with recipients to always vote for a particular recipient in exchange for a kick-back. But assuming those pitfalls were overcome, we would see different projects competing to serve the interests of the miners, whose vote they would need in order to receive funding.
However, this still leaves one critical issue unaddressed: the market price for infrastructure development.
How much development work should be done on BCH infrastructure? Suppose there are 10,000 software developers who are quite capable of working on BCH node development, but are currently working on printer drivers, the next big first-person-shooter, new video compression algorithms for streaming, etc. How many of these developers should quit their jobs and start working on BCH node development? If they start working on BCH, we will have to wait longer for printer drivers, video games and video streaming improvements. How do we decide how much of the available developer resources should be invested in each one?
The Austrian, Rothbardian, free-market answer is prices. We bid for these developers' time by offering them salaries or other funding. Whoever offers them the most money will generally get their attention. Some may have other personal values that affect their decision. Some may be willing to take a lower salary in exchange for getting to work on their passion project. That is fine, that's their choice. Their preferences are just as valid as any of ours. But the point is that the price system is what lets those developers know where their time is most valued. It may be that consumers want "lots more BCH development right now!" Or it may be that consumers are willing to wait longer for BCH improvements to be made, if it means that they get improved video compression sooner. The only way for the developers to find out what those consumer preferences are and balance them optimally is by a system of freely-fluctuating market prices for their time and effort.
What does this have to do with the IFP?
Let's say that we set the IFP block reward at 9% of the block reward (a number I chose arbitrarily). That means that the price of BCH development is fixed at 9% of the block reward. The amount of development that we will get is whatever 9% of the block reward can buy. If we want more development than that, we can potentially fund it through other fundraising sources, but that will become more difficult when everyone knows the "real" way to get funding is to convince miners to send you the IFP portion of their block rewards. On the other hand, if the market genuinely wants less development than 9% of block rewards would buy, we will never know it. We will pay 9% of block rewards, regardless of what consumers' real preferences are. The market will be distorted, and consumer preferences will not be satisfied as effectively as they might otherwise be.
In the scheme of things, this may only be a very slight distortion of the overall market for developer services. It might be a drop in the bucket, relatively speaking. But philosophically, it is very problematic. Price-fixing is inherently inefficient. This amounts to a form of central-planning of how much of our resources will be devoted to BCH infrastructure, rather than letting the market negotiate and adjust that amount towards whatever level is actually optimal.
We have seen that when people (including myself) called the IFP a "tax", they were making a subtle mistake. They noticed that the IFP boycott was going to decrease their available market options, and it was being done against their will. To that extent, they saw that they would suffer economic harm as a result, and instinctively assumed that economic harm done to them against their will was probably coercive. But economic harm is not the same as coercion. Economic harm can happen from natural disasters, or from people's exercise of their rights for non-economic reasons (such as boycotting a racist grocery-store owner). Therefore, it is ultimately not accurate to call the IFP a "tax".
However, the IFP is still a boycott. It involves choosing short-term economic harm for ourselves in order to pressure particular actors into doings things that we hope will bring us long-term economic gain.
The problem is, the thing we want them to do is a form of price-fixing, or central economic planning. Central economic planning tends to be economically harmful rather than helpful, because it distorts price signals and prevents the market from finding the optimal distribution of resources for the satisfaction of consumers' desires.
For these reasons, I conclude that the IFP is a bad idea that will not be economically beneficial to the BCH ecosystem. But I do not believe that the IFP is coercive, that it is a tax, or that it is an invasion of anyone's property rights.